Do you have a particular objection to adopting the Tomcat scheme, which Craig and I, at least, prefer over the HTTPD scheme? Can't we just settle on the Tomcat scheme and move on?
-- Martin Cooper On Wed, 20 Oct 2004 01:02:35 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > > Terminology isn't the important part to me -- voting is. That's > > why I prefer approach (b). > > I believe assigning a milestone number to a distribution and tagging the repository > with that number promotes voting. The vote can be on a precise entity: what is > tagged in the repository for the given milestone and represented by the distribution. > > It might be helpful to adopt the convention of adding an "ALPHA" marker to new > milestones. A distribution file name could start out in the form > "struts_1_2_5_ALPHA.zip". An alpha marker in the file name would make it very clear > that this is not a formal distribution. > > If the milestone is voted to Beta or General Availability, then we could drop the > ALPHA marker, and if appropriate, submit the Beta or General Availability > distribution for mirroring. > > The solution for "dictatorial release managers" is to prevent the position from > being institutionalized. IMHO, a new rule should be that the first thing a new > Committer must do is roll the next milestone :) > > So long as any of us can roll a milestone release, then the PMC will always be able > to vote on whatever milestone it deems worthy. The board has made it very clear that > all protected code must be in an Apache repository, and we all have a vote as to > what goes into the repository. > > I like the HTTPD protocol because it is clean and effective. We roll the > distribution, tag the repository, and (essentially) vote on the tag. The process is > unambiguous and repository-driven. If we want safeguards, then let's put "alpha" in > the name of a new-born milestone, and make sure the release process is something any > one of us can initiate. > > -Ted. > > > > On Tue, 19 Oct 2004 10:00:42 -0700, Craig McClanahan wrote: > > Semantics and terms aside, there is a key difference between the > > approaches being discussed: > > > > (a) In the HTTPD way, the release manager can post a release > > (prejudged to be alpha quality) with a formal version number, with > > no vote from the rest of the PMC. > > > > (b) In the Tomcat way, the release manager can post a test build > > (essentially a release *candidate*) that still needs to be voted on > > to be actually released. > > > > Approach (a) seems to be what bothers Martin, and I'm uncomfortable > > with it as well. It works as long as you don't have any RMs with > > delusions of grandeur, trying to be dictatorial about where a > > project heads -- we haven't had that problem, but why make it > > possible? Approach (b) requires a positive action on the part of > > the PMC to do anything more than a test build, and gives the > > community of users a sense that we're all behind this release. > > > > Terminology isn't the important part to me -- voting is. That's > > why I prefer approach (b). > > > > Craig > > > > On Tue, 19 Oct 2004 04:32:30 -0400, Ted Husted <[EMAIL PROTECTED]> > > wrote: > > > >>> A release requires a vote, whereas a build does not. Also, > >>> referring to a test build as alpha is prejudging the quality of > >>> the build; it could be better than that, or it could be worse, > >>> and IMNSHO it reflects badly on us if we first claim it's alpha > >>> and later are seen to change our minds about that, whichever > >>> way the change goes. > >>> > >> > >> The Apache HTTPD team prejudges their builds as "Alpha". > >> <http://httpd.apache.org/dev/release.html> > >> > >> Each of us vote when a commit is made, even if it is a lazy vote. > >> > >> AFAIK, the ASF Board has never, ever defined what does and does > >> not require a vote. They've delegated that decision to the Struts > >> Vice President and PMC. Something requires a vote if we say it > >> requires a vote. Likewise for not requiring a vote. > >> > >> IMHO, people are applying shades of meaning to the words > >> "release", "build", and "distribution", that are unintended by > >> the Foundation and elude our users. > >> > >> The operative words are "automated" or "nightly" and "Alpha", > >> "Beta", and "General Release". > >> > >> There is no point in reinventing terminology that other teams -- > >> well experienced in the art and science of creating releases -- > >> have already clearly defined. > >> > >> Again, here's my +1 for adopting the HTTPD release protocol, with > >> the one modification of using the term "Alpha build" in lieu of > >> "Alpha release". > >> > >> -Ted. > >> > >> > >> On Mon, 18 Oct 2004 22:59:48 -0700, Martin Cooper wrote: > >> > >>> On Mon, 18 Oct 2004 18:39:43 -0500, Eddie Bush > >>> <[EMAIL PROTECTED]> wrote: > >>> > >>>> When you say "test build", do you mean "alpha release"? The > >>>> two terms are synonymous in my mind, so voting on an alpha > >>>> isn't something I'd ever think of as that's what I view the > >>>> nightly builds to be. > >>>> > >>>> > >>> A release requires a vote, whereas a build does not. Also, > >>> referring to a test build as alpha is prejudging the quality of > >>> the build; it could be better than that, or it could be worse, > >>> and IMNSHO it reflects badly on us if we first claim it's alpha > >>> and later are seen to change our minds about that, whichever > >>> way the change goes. > >>> > >>>> I do believe we should be voting on Beta and up though. Beta > >>>> should (hopefully) be bug-free -- a build we anticipate to be > >>>> the "major release". Perhaps my thinking is flawed :-) > >>>> > >>>> > >>> Have you ever experienced bug-free beta software? For that > >>> matter, have you ever experienced bug-free software at all? ;-) > >>> > >>> -- > >>> Martin Cooper > >>> > >>> > >>>> ----- Original Message ----- > >>>> From: "Craig McClanahan" <[EMAIL PROTECTED]> To: "Struts > >>>> Developers List" <[EMAIL PROTECTED]> Sent: Monday, > >>>> October 18, 2004 2:25 PM > >>>> Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: > >>>> [Announce] Release of Struts 1.2.5 (beta)) > >>>> > >>>>> +1 on the "test build then vote to rank" approach that > >>>>> Tomcat uses. > >>>>> > >>>>> As an additional clarification, I presume that we will want > >>>>> the same release process for any subproject releases? This > >>>>> is becoming timely as the opportunity for a 1.0.1 release > >>>>> of struts-faces draws nigh. It might be worth mentioning > >>>>> this in the release guidelines as well, including the > >>>>> explicit requirement that any release vote involve the > >>>>> entire committer community (with PMC votes binding, as > >>>>> usual) -- not just the developers who might happen to be > >>>>> working on that subproject. After all, the subprojects will > >>>>> still say "Struts" on them, and we're all going to care > >>>>> about that reputation. > >>>>> > >>>>> Craig > >>>>> > >>>>> > >>>>> On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska > >>>>> <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>>> At 10:55 AM -0700 10/18/04, Martin Cooper wrote: > >>>>>> > >>>>>>> The 1.2.1 and 1.2.2 test builds didn't make it to > >>>>>>> releases. That is as it should be - we want releases to > >>>>>>> be quality builds. > >>>>>>> > >>>>>>> What I feel very strongly about is that nothing should > >>>>>>> be called a Release until we vote on it, especially > >>>>>>> since I believe this is an ASF requirement. We have > >>>>>>> said that anyone can build a Test Build (e.g. 1.2.x) at > >>>>>>> any time, and that's fine. But I don't want to see such > >>>>>>> a build viewed as a Release by the community if the > >>>>>>> developers / PMC haven't sanctioned it by a vote. > >>>>>>> > >>>>>>> > >>>>>> I think ultimately we agree even more than I realized, > >>>>>> since, looking back at how you describe these events, I > >>>>>> realize that my main concern - version number confusion - > >>>>>> is not at issue. > >>>>>> > >>>>>> I simply think of anything with a version number as a > >>>>>> release. I'm happy to change that and to describe the > >>>>>> first output of the "release process" as a "test build" > >>>>>> instead of an "alpha release". > >>>>>> > >>>>>> In fact, I'd be +1 to that, given that we have two cases > >>>>>> in recent memory where the artifact was not really even > >>>>>> usable as an alpha release. > >>>>>> > >>>>>> > >>>>>> Joe > >>>>>> > >>>> > >>>> --- > >>>> avast! Antivirus: Outbound message clean. > >>>> Virus Database (VPS): 0442-3, 10/15/2004 > >>>> Tested on: 10/18/2004 6:39:44 PM > >>>> avast! - copyright (c) 2000-2004 ALWIL Software. > >>>> http://www.avast.com > >>>> > >>>> > >>>> -------------------------------------------------------------- > >>>> ---- --- To unsubscribe, e-mail: dev- > >>>> [EMAIL PROTECTED] For additional commands, e- > >>>> mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> ---------------------------------------------------------------- > >>> ---- - To unsubscribe, e-mail: dev- > >>> [EMAIL PROTECTED] For additional commands, e-mail: > >>> [EMAIL PROTECTED] > >>> > >> > >> ------------------------------------------------------------------ > >> --- To unsubscribe, e-mail: [EMAIL PROTECTED] For > >> additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > -------------------------------------------------------------------- > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
