From general-return-10921-apmail-incubator-general-archive=incubator.apache.org@incubator.apache.org Wed Sep 13 17:27:01 2006 Return-Path: Delivered-To: apmail-incubator-general-archive@www.apache.org Received: (qmail 59646 invoked from network); 13 Sep 2006 17:26:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Sep 2006 17:26:58 -0000 Received: (qmail 79163 invoked by uid 500); 13 Sep 2006 17:26:56 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 79029 invoked by uid 500); 13 Sep 2006 17:26:56 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 79018 invoked by uid 99); 13 Sep 2006 17:26:56 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Sep 2006 10:26:56 -0700 Authentication-Results: idunn.apache.osuosl.org header.from=robertburrelldonkin@gmail.com; domainkeys=good Authentication-Results: idunn.apache.osuosl.org smtp.mail=robertburrelldonkin@gmail.com; spf=pass X-ASF-Spam-Status: No, hits=0.4 required=5.0 tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates 66.249.92.172 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from ([66.249.92.172:2463] helo=ug-out-1314.google.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id 9F/A1-10245-8DE38054 for ; Wed, 13 Sep 2006 10:25:55 -0700 Received: by ug-out-1314.google.com with SMTP id u40so2001790ugc for ; Wed, 13 Sep 2006 10:24:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O7JynGvjc8MxxhDG5rb2EbQSfXzHX1PU5PDK8i8E5x0yL10xvKXrHPIpROkKHod7Zol4JUwAbY03QUUb045imlOC/361bCGk1i1uPRs85ewRVwInr/SRsphRGLl4qnxn/kAmsXRTJYNnIEK0nOD0Z5SGtciey8s7699xDxqF480= Received: by 10.67.97.18 with SMTP id z18mr4228890ugl; Wed, 13 Sep 2006 10:24:20 -0700 (PDT) Received: by 10.67.30.13 with HTTP; Wed, 13 Sep 2006 10:24:19 -0700 (PDT) Message-ID: Date: Wed, 13 Sep 2006 18:24:19 +0100 From: "robert burrell donkin" To: general@incubator.apache.org Subject: Re: Podling Release Requirement (WAS: Re: [VOTE] Graduate Felix to TLP status) In-Reply-To: <4508295C.3040406@bellsouth.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7a31ebb30609130622p3f28e66av12834616295ff006@mail.gmail.com> <4508295C.3040406@bellsouth.net> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 9/13/06, Alex Karasulu wrote: > J Aaron Farr wrote: > > On 9/13/06, Justin Erenkrantz wrote: > >> On 9/12/06, Niclas Hedhman 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 conflicting the 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/%3cNBBBJGEAGJAKLIDBKJOPAEIPHMAC.noel@devtech.com%3e > > 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. 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. 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). > > 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 least > one incubator release a requirement for graduation? I think if we're > going to hold it as a blocker before graduation we must make it a rule > to be absolutely clear. i do not think that having made a release should be a requirement; 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. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org