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 Fri, 28 Sep 2007 07:40:59 GMT
On 9/28/07, Niclas Hedhman <> wrote:
> On Friday 28 September 2007 05:12, Yoav Shapira wrote:
> > Personally, that's my take on it, and what I've done historically.
> I agree with Yoav, but would like to add that I personally have different
> standards for different podlings, i.e.
> - The sooner one can expect graduation -> higher bar.
> - Projects with many existing ASFers in it -> higher bar.
> - Projects with high visibility outside Incubator, such as
>    some sponsored ones -> higher bar.
> One problem we are facing is that we are unable to track the "delta" of
> issues
> from one release to the next. If we could, then things would be so much
> easier.
> And don't forget, many projects are aiming for one perfect release to
> graduate...
> I think the end result of "rather strict than lenient" improves ASF legal
> quality over time, as these concerns will "rub off" on less than perfect
> reviews in other projects through the participation of individuals.
> Cheers
> Niclas

It sounds reasonable to make part of the graduation criteria being able to
demonstrate some competence in making releases, and thats already on the
graduation checklist in the Incubator policy and graduation guide.  I know
there's no simple way to keep track of  all the issues over all the releases
but that could be part of the review required when deciding how to vote on a
graduation proposal - trawling through the mailing list to see how their
releases went. So couldn't the decision on whether or not to respin a
release still be left up to the the podling anyway? If they're thinking
about graduation and its important to them to be able to demonstrate a
perfect release let them choose to respin themselves.

I'm less keen on having different standards for different projects. One of
the difficulties for incubating projects is finding out about all the
release requirements. One way i've found to do that is by looking at what
other releases do but when the same issues aren't flagged for some releases
it can be quite confusing what the actual requirements are.

Making most issues non-blocking could actually improve reviews as in some
cases it could be easier to mention an issue it if its not going to force a

Anyway, so i'm thinking more of a benevolent educator than traffic warden
style reviewer role.


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