On 9/28/07, Niclas Hedhman <[EMAIL PROTECTED]> 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 ws.apache.org 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 respin. Anyway, so i'm thinking more of a benevolent educator than traffic warden style reviewer role. ...ant
