On Sep 13, 2006, at 10:24 AM, robert burrell donkin wrote:
On 9/13/06, Alex Karasulu <[EMAIL PROTECTED]> wrote:J Aaron Farr wrote: > On 9/13/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote: >> On 9/12/06, Niclas Hedhman <[EMAIL PROTECTED]> wrote:>> > As Leo pointed out, 'codebase quality' is not a graduation criteria.>> And>> > (hopefully) with Upayvira as the initial PMC Chair, I am not worried>> that the>> > PMC will overlook release requirements. If ASF Members feel that to>> be a>> > concern, they are both free to monitor and participate in the PMC work.>>>> My concern has nothing to do with 'codebase quality', but asking for a >> demonstration that the Felix community understands how to conduct a>> release that meets the ASF's criteria. >> >> If the community produces a release that is perfect on first shot,>> great - they're truly ready to graduate. If not, well, then, they'll>> learn from those mistakes and once they can produce a release that >> meets our criteria, then they'll be ready to graduate. >> >> Remember that a major task for a TLP is conducting a release.>> Therefore, it's reasonable for the Incubator PMC to ask for proof that>> they will execute that task successfully rather than taking it on >> blind faith. -- justin > > And I'm fine with that. I think it's a good idea for Incubating > projects to do at least one release before graduating. > > My concerns are: >> 1) The policy regarding podling releases has never been explicit and> always been conflictingthe formal policy(http://incubator.apache.org/incubation/ Incubation_Policy.html#Releases)isn't too bad (though i have tidied up the verbage surrounding it recently). the sentiment towards releases has definitely changed as we've leant more about the process. the PMC is now agnostic rather than antagonistics.Originally we (the mentors) and even Noel had told Felix not to worry about a release within the incubator:http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/ 200604.mbox/[EMAIL PROTECTED]So both mentors and the Incubator PMC Chair told these folks that a release was not the primary objective for graduation. We explicitly told them *NOT* to worry about a release until after graduation. And graduation, we thought, was right around the corner.i agree that releases should not be a primary objective for graduation.
+1
IMO the question is not about performing a release (which is high ceremony) but about knowing how to perform a release that complies with ASF policy.
+1
since we started checking releases in detail, it's become clear that most projects struggle to create a compliant release at the first attempt. nearly every first attempt checked turns out not be compliant. i didn't expect this (since the rules are really pretty simple).
I only slightly beg to differ over Robert's characterization of the Apache release rules as "simple". Not.
> 2) Let's not (again) fall into the trap of changing the requirements> of graduation (or entry for that matter) on a vote thread > > So could we move these discussions to a new thread?Yeah good idea. Let's start off by discussing whether we make at leastone incubator release a requirement for graduation? I think if we'regoing to hold it as a blocker before graduation we must make it a ruleto be absolutely clear.i do not think that having made a release should be a requirement;
+1
personally speaking, i would not support the gradudation any project that has not demonstrated that they understand the apache releases policy. doing this is much easier and quicker than creating a proper release. just nominate a release manager and post a compliant example to the people.apache.org webspace using the current code base so that it can be checked.
Having struggled through the release process outside the incubator, I can attest to the value that the incubator PMC brings to the process. I'd support changing the incubator process to encourage "what Robert said". That is, as a requirement (recommendation?) for graduation, have the podling nominate a release manager, have her build a candidate release that conforms to Apache policy, and post it for review.
Craig
- robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
