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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
