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]

Reply via email to