On Tue, 19 Oct 2004 10:00:42 -0700, Craig McClanahan <[EMAIL PROTECTED]> 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).
+1. You hit the nail on the head with respect to voting being the key. I do think that the terminology is important, though, in the sense that we need to be clear in communicating with our users / customers. And I think the Tomcat terminology is very clear. When we first started discussing changes to the way we build and release Struts, the model that was proposed was the Tomcat model, and that is still the model I would like to see us follow, terminology and all. -- Martin Cooper > > 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: [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]
