Re: discussion of release

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Tomcat-folk,

Since there is still a bit of confusion about releases, here is what Leo had
to say on the subject of releases earlier today on general@Incubator.a.o.
I found this to be a really useful Q&A style dialog.

I've simply replaced the "podling" or "PPMC" through with [Release Manager],
[RM] or [committer], and "IPMC" with "PMC" throughout, as applicable.  But
I think Leo's words will ring clearer to some folks than my own, we all
parse things differently.

Leo Simons wrote:
[...]
> 
>> On Apr 12, 2007, at 2:39 PM, Leo Simons wrote:
>>
>>> There's just this one little tidbit - if the [PMC] votes to *release*
>>> something, that something should then actually be released. "Release"
>>> has a specific meaning and we (have to) do "distribution at no charge
>>> to the general public" of them. I guess it's all in a name.
>>
>> I guess I don't quite understand the issue you are raising. If the
>> [PMC] votes to release something, then it goes back to the [Release
>> Manager (RM)] to make it happen. I don't see the [PMC] as actually 
>> "releasing" anything. All it does is to approve a [...] release, and 
>> then it's up to the [RM] to take the next step.
> 
> I understand your interpretation, but I'm afraid it's simply not how we
> need to think about these things. Releasing software is done
> officiallly, on behalf of the ASF (which is a good thing because the ASF
> is then responsible, and liable, for the release, not an individual
> release manager). The only ways to do things officially on behalf of the
> ASF are
> 
>   (1) an Officer of the foundation does it
>   (2) a board member of the foundation does it
>   (3) a Committee that was specifically delegated to do
>       specific things in accordance with the foundation
>       bylaws does the specific thing that was delegated
>       to it
> 
> [An RM] is not a 'real' office set up by the board, so [they] cannot act
> on behalf of the ASF. Because of this, whenever "acting on behalf of the
> ASF" must be done for [a] project, the [PMC] has to do the acting.
> 
> In this terminology, the "acting" is embodied in the release vote.
> Actually creating and moving the files around is something more like
> "administrative grunt work" if you will.
> 
>> If the [release manager] discovers something else that's wrong, or for 
>> some other reason decides not to release, are you suggesting that somehow
>> the [PMC] is going to go and release it anyway?
> 
> Given the above, for all intents and purposes, after a release vote has
> concluded, the thing that was voted on has been released.
> 
> An in-progress vote can be canceled.
> 
> After a vote has concluded, a release can still be "pulled". And we
> don't seem to vote on pulling a release, it is just administrative action.
> 
>>> The alternative is to *not* release something, and then there should
>>> not be a release vote, but a different kind of vote, or no vote at all.
>>
>> Well, I guess I don't see this the same way. I understand that the
>> [PMC] doesn't want to waste its valuable (!) time reviewing stuff that
>> has no intrinsic value, but if a [committer] is at the point of wanting
>> to make sure it knows how to release, and has all the necessary IP
>> clearance, copyright notices, readme, and disclaimers, why not have a
>> release vote?
> 
> Because a release vote is an official part of the ASF processes that is
> as official as it is for specific reasons, it serves a specific purpose,
> and should serve only that purpose.
> 
> Doing things this way is part of the "legal umbrella" that the ASF
> provides its projects, and the strength of that umbrella depends (I
> think) in part on everyone following the same basic steps.
> 
> hope this helps,
> 
> - Leo

[Adapted for general PMC use by Bill]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org