You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/08/26 00:55:49 UTC
Re: [lang] Doing the release
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" <ba...@generationjava.com>
> 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: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
>
Re: [lang] Doing the release
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i lost interest since it became clear that the original use i wanted to
make of the code (in beanutils) wasn't going to happen.
i've now become interested in the possibility of using reflection for unit
tests of (for example) gui components. it's common to want to code these
fairly tightly. some of the code in there which (given the right security
environment) gives the sort of clean clear interface that's needed for
unit tests. so maybe i'll find some time to revisit [reflect].
- robert
On Wednesday, August 27, 2003, at 02:00 AM, Stephen Colebourne wrote:
> [reflect] is intended to take the current stalled [lang.reflect] code and
> make it a separate project. This would include reflection (with method
> caching) and maybe C# style features.
>
> Stephen
>
> ----- Original Message -----
> From: "__matthewHawthorne" <mh...@alumni.pitt.edu>
>> What's the status of the sandbox component [clazz]? I believed this to
>> be a project including reflection utilities, but I might be mistaken.
>> Is this a different project than what you're suggesting in [reflect]?
>>
>> As far as [io] is concerned, I'm hoping to submit a patch or two this
>> week, mostly focusing on improving the test coverage and simplifying the
>> api. Since Jeremias is on vacation for 2 weeks or so, if any committers
>> would keep their ears to the ground and take a look at my patches I
>> would appreciate it.
>>
>>
>>
>>
>> Stephen Colebourne wrote:
>>
>>> 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" <ba...@generationjava.com>
>>>
>>>
>>>> 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: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
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [lang] Doing the release
Posted by Stephen Colebourne <sc...@btopenworld.com>.
[reflect] is intended to take the current stalled [lang.reflect] code and
make it a separate project. This would include reflection (with method
caching) and maybe C# style features.
Stephen
----- Original Message -----
From: "__matthewHawthorne" <mh...@alumni.pitt.edu>
> What's the status of the sandbox component [clazz]? I believed this to
> be a project including reflection utilities, but I might be mistaken.
> Is this a different project than what you're suggesting in [reflect]?
>
> As far as [io] is concerned, I'm hoping to submit a patch or two this
> week, mostly focusing on improving the test coverage and simplifying the
> api. Since Jeremias is on vacation for 2 weeks or so, if any committers
> would keep their ears to the ground and take a look at my patches I
> would appreciate it.
>
>
>
>
> Stephen Colebourne wrote:
>
> >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" <ba...@generationjava.com>
> >
> >
> >>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: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
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >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
>
Re: [lang] Doing the release
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 25 Aug 2003, __matthewHawthorne wrote:
> As far as [io] is concerned, I'm hoping to submit a patch or two this
> week, mostly focusing on improving the test coverage and simplifying the
> api. Since Jeremias is on vacation for 2 weeks or so, if any committers
> would keep their ears to the ground and take a look at my patches I
> would appreciate it.
I'm an IO committer, so perfectly happy to take a look etc.
Hen
Re: [lang] Doing the release
Posted by __matthewHawthorne <mh...@alumni.pitt.edu>.
What's the status of the sandbox component [clazz]? I believed this to
be a project including reflection utilities, but I might be mistaken.
Is this a different project than what you're suggesting in [reflect]?
As far as [io] is concerned, I'm hoping to submit a patch or two this
week, mostly focusing on improving the test coverage and simplifying the
api. Since Jeremias is on vacation for 2 weeks or so, if any committers
would keep their ears to the ground and take a look at my patches I
would appreciate it.
Stephen Colebourne wrote:
>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" <ba...@generationjava.com>
>
>
>>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: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
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>