Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of robertburrelldonkin@gmail.com
 designates 66.249.82.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=mfYgja1wmKCUbLH3JIRc+HRacFwPAxQNBSMV7wbKa8H9QLZC8pgDCKPs1sEtMKSIQ+TpsWywQfVkv454QSFP+/ti082zEdUKIZ1gj1Id9TPwKi3lCiygOHrRMysD2N2ZDRzobqVbfgZJsOos0BmB7hjnvis6kDnRupkkmDJi51I=
Message-ID: <f470f68e0710031302k25e959a1y3b7310cae781bae4@mail.gmail.com>
Date: Wed, 3 Oct 2007 21:02:08 +0100
From: "Robert Burrell Donkin" <robertburrelldonkin@gmail.com>
To: general@incubator.apache.org, antelder@apache.org
Subject: Re: How strict should podling release reviews be?
In-Reply-To: <71e1b5740710030810t25620cb8u4a407f15e9663745@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <71e1b5740709280040v4037bb64s1e7f7830ccd5ecd0@mail.gmail.com>
	 <NBBBJGEAGJAKLIDBKJOPGEMMAKAD.noel@devtech.com>
	 <f470f68e0710021438p277c59d4pbf835c77d8a28ee3@mail.gmail.com>
	 <71e1b5740710030810t25620cb8u4a407f15e9663745@mail.gmail.com>

On 10/3/07, ant elder <ant.elder@gmail.com> wrote:
> On 10/2/07, Robert Burrell Donkin <robertburrelldonkin@gmail.com> wrote:
> >
> > On 10/2/07, Noel J. Bergman <noel@devtech.com> 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 http://wiki.apache.org/incubator/RatProposal 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
> things.

hopefully it will be easy to contribute in small ways without too much
effort. this is particularly important since a lot of meta-data needs
to be collected. this probably isn't feasible without active help from
contributors.

for example, a good guessing algorithm for generated files needs good
meta-data about the ways common programs mark files as generated. so
release managers can contribute by submitting new patterns whenever
RAT doesn't correctly recognize a generated file.

another example, discordia aims to collect meta-data allowing
artifacts to be matched to license meta-data. when release managers
encounter a jar (or other binary artifact unknown to discordia) they
can submit meta-data.

> Until that gets implemented (or maybe as part of its design?) could there be
> a wiki page documenting each rule RAT would check?

RAT just automates tedious checks that reviewers carry out by hand.
again, this is going to require collection of meta-data analysis rules
for automation.

> 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.

different people have different ideas about what are blockers and IMHO
this is good

i've seen very few -1's, what's much more common is for people with
criticisms to post them and not offer a vote

i would expect a -1 only if the apache policies were broken

> 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 :)

IMHO the wiki is just a distraction: the real problem is that the
release management page is very unfinished. if there are people with
time then improving would be great. volunteers?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org