incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ant elder" <>
Subject Re: How strict should podling release reviews be?
Date Wed, 03 Oct 2007 15:10:33 GMT
On 10/2/07, Robert Burrell Donkin <> wrote:
> On 10/2/07, Noel J. Bergman <> wrote:
> > > i'm thinking more of a benevolent educator than traffic warden
> > > style reviewer role.
> >
> > When it comes to legal issues related to a release, the warden role is
> the
> > more appropriate.  It benefits neither the project nor the ASF if we are
> lax
> > in that regard.
> >
> > Some of the things that they need to do are identified by RAT, and would
> be
> > non-issues if they would correct their build process to do them
> > automatically, e.g., inserting the license and disclaimer files where
> they
> > are supposed to go.
> i do believe that there's a definite problem here. there's too much
> energy wasted by everyone.
> the IPMC cannot actively oversee the code bases without automation.
> so, the only real oversight happens at release time. this is bad for
> everyone. really, we need to automatically scan and analyse the
> incubator codebases.
> i hope that may help

That RAT proposal looks really good, its just what we need. I can't promise
to contribute much code but i'd definitely hang around and help test it on

Until that gets implemented (or maybe as part of its design?) could there be
a wiki page documenting each rule RAT would check? That way  we could have a
complete list of each specific requirement in one place to make it easier
for both podlings and reviewers to check manually till RAT is done. If we
had such a list then it could be only the things documented there are
release blockers, or at least if a release is blocked the reason should get
added to the list so we eventually have a fairly compressive list of the
rules so everyone knows what to expect.

I'd have a go at creating such wiki page with the rules I know about if
people think its useful but i expect others would need to help out if its
going to get very comprehensive :)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message