Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of shanti.subramanyam@gmail.com
 designates 209.85.220.214 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=se+a6RKBVpRq1sKzBwJ8J4e86F6wZjGgIlLhEcrHjx7MaAIPNCQ7D6P0cPLeosk6fB
         nymCAGJqDNlOJVIbq1GM8Swk393DzEZKHHowVcnP//hsRO1HiJu8juZjaykZNpIh7tSY
         vy/QwlwoSnXlONnxCDXd3KNaOMjEvygggymX8=
Message-ID: <4AF9A08B.1030607@gmail.com>
Date: Tue, 10 Nov 2009 09:19:07 -0800
From: Shanti Subramanyam <shanti.subramanyam@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: Insanity (of the release process)
References: <30b2aef60911090816r269aa5b7rff3ffd335d4a96c5@mail.gmail.com>
	 <4AF92D4E.5080004@rowe-clan.net>
	 <6cca3db30911100805h1366cb94k146759e503d92bf4@mail.gmail.com>
 <30b2aef60911100822v2a2f5acdy379ed54ac03e24ed@mail.gmail.com>
In-Reply-To: <30b2aef60911100822v2a2f5acdy379ed54ac03e24ed@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I like Leo's proposal. With PMC members mentoring multiple projects, it 
is really a burden to try and get 3 votes for a release.

Shanti

Leo Simons wrote:
> On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein <gstein@gmail.com> wrote:
>   
>> On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>>     
>>> Leo Simons wrote:
>>>       
>>>> Here's what I understand:
>>>>
>>>> 1) Apache rule: all apache releases must be made by PMCs
>>>> 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s
>>>> 3) from #1 and #2 it follows that all incubator releases must be made
>>>> by the incubator PMC
>>>>         
>>>> If you see a way to fix this mess, please do. I suspect rule #1 is the
>>>> whopper that is just quite hard to get around and from it follows a
>>>> lot of other mess. I don't know exactly where that rule comes from,
>>>> but it is very old and it has always seemed very solid, too. IANAL.
>>>>         
>>> Mechanically, it's possible to recharter Incubator PMC as a board committee
>>> which has the authority to assemble and dissolve fully empowered PPMCs so
>>> they could begin binding votes from the outset.  The 'P' would change from
>>> 'pre' to 'provisional'.  I don't know if this is what we want to do, or not.
>>>       
>> The Board is trying to move away from Board committees.
>>
>> The IPMC is in charge of its operation. It can redefine the rules of
>> releases as it pleases. The three +1 rule was developed to show that
>> the PMC is "in charge" of the release, and is therefore legally liable
>> for it. The IPMC can do whatever it likes around releases, as long as
>> that process specifically claims or disclaims liability.
>>     
>
> Ok, that is interesting (and probably more workable than a big reorg).
> I still think we should claim liability.
>
> Could we, for example, have a release process that is lazy-by-default
> from the IPMC side and still claim that the ASF gets liability?
>
> for example, to release:
>
> 1) PPMC must vote for the release according to their rules (which
> should at least match the 3 +1 / majority rule requirements)
> 2) at least one PMC member must vote +1 (usually the mentor)
> 3) if there are no -1 votes, the PPMC sends the general@ list a
> request for a release ACK, after they get that ACK from a PMC member,
> they wait for 72 hours, and if there are still no -1s, the release is
> approved.
> 4) if there are any -1 votes, then the rule becomes the normal 3 +1s
> from PMC members / majority
>
> Downside:
> * more complex
> * increased dependency on single person to teach the "basics"
>
> Upside:
> * better reflects relationship between incubator and PPMC
> * more responsibility for project
> * hopefully fewer stalled releases
>
> thoughts?
>
> Leo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>   


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