Quoting Martin Cooper <[EMAIL PROTECTED]>: > The issue isn't so much with voting on the relesae plan, but voting on the > release itself. As you say, the HTTPD rules say that anyone can create a > release. We're not HTTPD, though, and the Jakarta rules are different. As > long as we're part of Jakarta, we need to abide by the Jakarta rules. > > Under "Decision Making", in the section on "Release Testing", is the > following statement: > > "Majority approval is required before the release can be made." > http://jakarta.apache.org/site/decisions.html > > So, we do need to vote on each and every release. >
The Tomcat folks do indeed vote on every release -- they just do things in a little different order: * Post what amounts to a release candidate and announce to a limited audience (dev and user lists) asking for testing. * Testing ensues ... * Call a vote on the release, with the options to call it alpha, beta, stable (that's fine with me), or withdraw (if there was some bad problem). * Announce to the world and do the usual process of distributing the bits. The same approach would work for us, and IMHO meets the Jakarta requirements with one additional wrinkle -- the Jakarta PMC needs the opportunity to vote on releases as well, to be consistent with the current ASF reqirements. +1 on the 1.2.0 release plan, by the way. > -- > Martin Cooper Craig > > > > On Tue, 16 Dec 2003, Ted Husted wrote: > > > With this proposal, I took a middle ground. The initial minor release > > (x.x.0) in a series called for a vote on a plan, but a plan would be > > optional for additional releases in the same series (1.2.1, 1.2.2, ...). > > So, we wouldn't have to vote on a plan again until we get to 1.3.0 or > > 2.0.0. > > > > The rationale is that starting a new series (1.2.0 versus 1.1.0) is a > > decision upon which we should have a formal consensus. After that, > > issuing additional point releases in the same series can be "business as > > usual" . > > > > Of course, this is just a vote on the plan. Once we roll the release, > > there would be another vote on whether to take that specific entity from > > Alpha to Beta and/or General Availability. (Though, personally, I prefer > > the more common "stable" designation to GA.) > > > > Of course, as the HTTPD guidelines point out, under the Apache License, > > anyone can distribute a release of our codebase. It's just a matter of > > whether it can be called "Struts" or not. :) > > > > -Ted, > > > > Martin Cooper wrote: > > > +1 > > > > > > I've added myself as an RM, since I'll be available to help. I can take > on > > > the tag, roll, sign and announce part, if you like. > > > > > > One thing I'd like to point out, because it came up in Commons, is that > > > the HTTPD process and the Jakarta process are not 100% compatible. In > > > particular, the Jakarta rules require a vote, while the HTTPD rules do > > > not. I suspect that this vote may be sufficient, but I'll check when I > get > > > a chance. > > > > > > -- > > > Martin Cooper > > > > > > > > > On Tue, 16 Dec 2003, Ted Husted wrote: > > > > > > > > >>I've amended the date on the (now venerable) 1.2.0 release plan for this > > >> weekend. > > >> > > >>http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html > > >> > > >>I believe the release notes are in good shape now. I already marched > > >>through most of the stale 1.0/1.1 tickets, and can mop up the rest in > > >>short order. I imagine there will be a few patches that we can apply, > > >>but I've carved out some time to work on such. > > >> > > >>Note that I've left room in the release plan for the idea of multiple > > >>managers. If someone were up for sheparding the tests, especially the > > >>example application testing, I'd welcome the help. Someone else could > > >>also sign up for the final tag, roll, and announce part of the job. Of > > >>course, if everyone is busy, I'll be happy to muddle through on my own. > :) > > >> > > >>Since this is a x.0 release, the plan calls for a majority vote. > > >> > > >>Here's my +1 > > >> > > >>-Ted. > > >> > > >> > > >> > > >> > > >> > > >>--------------------------------------------------------------------- > > >>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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
