Ah, well, in that sprit, then comments on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22719 would be appreciated but I do not expect this to go in 2.0 unless other folks like/need it.
Gary > -----Original Message----- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Monday, August 25, 2003 20:24 > To: Jakarta Commons Developers List > Subject: Re: [VOTE] Release of Commons Lang 2.0 [take 2] > > Gary Gregory wrote: > > I'll take the blame for causing any confusion on this one since I had > > committed these Javadoc changes "during" the vote, which was made more > > difficult due to the extremely long email delays caused by the current > batch > > of viruses going 'round. > > > > My thought was that we were indeed voting on the build based on tagged > > sources and that any new commits would be in a post >2.0 release (even > > though, these changes being Javadoc changes are "harmless" and > beneficial to > > the release IMHO ;-) > > > > If we want to implement a code freeze in our environment on top of using > > tags, we could do that. I guess we'd have to vote on it too :-) > > Sorry if I misunderstood things. I thought we were still adding things > to the release. I see no reason to freeze code if we have a tagged > release. I am +1 for releasing the code prior to the javadoc changes > that occurred during the vote or to adding them and retagging. If that > requires a new vote, then I am OK with that as well. > > In any case, we should not have to stop everything as we wait for the > release to go. I would also very much like to see 2.0 get out the door. > > Phil > > > > > Gary > > > > > >>-----Original Message----- > >>From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > >>Sent: Sunday, August 24, 2003 00:00 > >>To: Jakarta Commons Developers List > >>Subject: RE: [VOTE] Release of Commons Lang 2.0 [take 2] > >> > >> > >>>Well, if there is a question about policy/process, why not just freeze > >> > >>the > >> > >>>code and restart the vote? > >> > >>By tagging the CVS, he effectively has frozen the code for the Release. > I > >>was simply curious about the policy because, as I said, other projects > are > >>stricter. For example the HTTPd team has different rules > >>(http://httpd.apache.org/dev/release.html). > >> > >>A Release Manager makes a release build, and it is automatically an > alpha. > >>It becomes a beta release when at least three Committers have voted beta > >>status, and there are more +1 than -1. It becomes a GA release when at > >>least three Committers vote for GA (stable) status, and there are more > +1 > >>than -1. Notice that -1 is not a veto. Notice, also, that the package > >>itself may go through multiple status changes, but no packaging changes. > >>The only allowable change is renaming the file to reflect the change in > >>status; exceptions can be made if a change in the contents of the > tarball > >>(e.g., someone forgot to add the LICENSE file). Otherwise, if a change > in > >>the CVS needs to be incorporated, it becomes a new release (with a new > >>vote). > >> > >>Other projects, such as Avalon, also roll jars and then vote on them as > a > >>Release. So I was just asking to understand what is established as > policy > >>here. I wasn't challenging Henri's release. > >> > >> --- Noel > >> > >> > >>--------------------------------------------------------------------- > >>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]
