Ok, then with 'tomcat' reading of the rules, I can put the 1.1.1 back for limited testing and then say next week call for a vote on commons-validator to classify it.
I confused the issue by calling it an Alpha instead of a RC. -Rob > -----Original Message----- > From: Craig R. McClanahan> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
