Well, we want a release that works, so if that means waiting then thats how it goes. Don't want to miss the boat on any books or articles or other stuff though.
I'm marshalling [collections] hoping for a release soon. Perhaps if [lang] committers want something to do, the reflect code could be broken out into a sandbox [reflect]? Or the [lang] sandbox could be used. Or there could be a focus on [io]. I don't want to wait too long though, as [lang] feels like it might have the energy to get a 2.1 in a couple of months to fill in any 2.0 gaps. Also, I want to use [lang] at work! Stephen ----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]> > In addition to the question of us playing it a bit more by the rules, the > Jakarta website is in a bit of a transition for a week or so. I'd rather > not do any deploys until the move from daedelus to minotaur is complete, > so am suggesting we back off until then. This sound doable? > > Hen > > On Sun, 24 Aug 2003, 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 :-) > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
