[Validator] was Re: [VOTE] 1.2.0 Release Plan

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]
> 
>