commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [VOTE] Release of Commons Lang 2.0 [take 2]
Date Tue, 26 Aug 2003 05:10:18 GMT
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:phil@steitz.com]
> 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:noel@devtech.com]
> >>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: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message