You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Robert Leland <rl...@apache.org> on 2003/12/14 06:08:58 UTC
Re: [PROPOSAL] Agreeing new voting rules for Jakarta
Phil Steitz wrote:
> Noel J. Bergman wrote:
>
>>> It seems odd to me that code changes effectively require consensus,
>>> but a release would not. What am I missing here?
>>
>>
>>
>> All code in CVS is already there on consensus.
>
>
> As are the bugs ;-)
>
> Seriously, this seems like sort of a grey area between "technical,
> code-related" (so needing consensus) and "policy." The decision to
> cut a release has technical implications (e.g. backward
> compatability), but it is not a technical decision per se. I am not
> pushing for this, just trying to understand better how we look at
> releases.
There are two schools.
For Struts 0.5, 1.0 , 1.1 we used the criteria that all bugs had to
fixed or marked as later.
As a result between 0.5 and 1.0 took 12 months
and between 1.0 and 1.1 took 20 months.
For Struts 1.2 we agreed to switch to the x.y.z
style that Apache HTTPD and Tomcat are using, where you post the bits and
then call for a vote on stability (alpha/beta/general availability).
A release can also be withdrawn.
After a release there is often a flood of new users, and a few, usually
very few new bug reported.
More importantly there are improvements new users make and hopefully share
as they tinker with and extend Struts to make it fit their needs. It's
this synergy that is good for the project.
We tried it the other way first and while we were always making progress
on the software,
the development could have easily stagnated. Between Struts 1.0 and 1.1
we were fortunate enough
to vote in about 8 committers, each gave the software development a much
needed boost.
By releasing more often we hope to actually increase the quality, by the
fact of greater participation
from the app developers. It's easier to do this now in Struts since
presently it is in an evolutionary mode.
Also I would say that Tomcat and HTTPD are two of the most successful
projects Apache has
so they have to be doing something right.
> Phil
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] Agreeing new voting rules for Jakarta
Posted by Robert Leland <rl...@apache.org>.
Phil Steitz wrote:
> Robert Leland wrote:
>
>> Phil Steitz wrote:
>>
>>> Noel J. Bergman wrote:
>>>
>>>>> It seems odd to me that code changes effectively require consensus,
>>>>> but a release would not. What am I missing here?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> All code in CVS is already there on consensus.
>>>
>>>
>>>
>>>
>>> As are the bugs ;-)
>>>
>>> Seriously, this seems like sort of a grey area between "technical,
>>> code-related" (so needing consensus) and "policy." The decision to
>>> cut a release has technical implications (e.g. backward
>>> compatability), but it is not a technical decision per se. I am not
>>> pushing for this, just trying to understand better how we look at
>>> releases.
>>
>>
>>
>> There are two schools.
>> For Struts 0.5, 1.0 , 1.1 we used the criteria that all bugs had to
>> fixed or marked as later.
>> As a result between 0.5 and 1.0 took 12 months
>> and between 1.0 and 1.1 took 20 months.
>>
>>
>> For Struts 1.2 we agreed to switch to the x.y.z
>>
>> style that Apache HTTPD and Tomcat are using, where you post the bits
>> and
>> then call for a vote on stability (alpha/beta/general availability).
>> A release can also be withdrawn.
>>
>> After a release there is often a flood of new users, and a few,
>> usually very few new bug reported.
>> More importantly there are improvements new users make and hopefully
>> share
>> as they tinker with and extend Struts to make it fit their needs.
>> It's this synergy that is good for the project.
>>
>> We tried it the other way first and while we were always making
>> progress on the software,
>> the development could have easily stagnated. Between Struts 1.0 and
>> 1.1 we were fortunate enough
>> to vote in about 8 committers, each gave the software development a
>> much needed boost.
>>
>> By releasing more often we hope to actually increase the quality, by
>> the fact of greater participation
>> from the app developers. It's easier to do this now in Struts since
>> presently it is in an evolutionary mode.
>>
>> Also I would say that Tomcat and HTTPD are two of the most successful
>> projects Apache has
>> so they have to be doing something right.
>>
>
>
> Thanks for the perspective, Robert.
>
> Does this mean you are in favor of having release votes just require
> majority approval?
I am in favor of releases requiring no vote. Only the classification of
whether it is a Alpha, Beta, GA
quality release needs a vote. Again this is a project/sub-project decision.
>
> After re-reading http://jakarta.apache.org/site/decisions.html
> carefully, I am in favor of keeping things as stated there -- Release
> Plans require lazy majority, but Release Testing just requires
> majority approval.
>
> Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [PROPOSAL] Agreeing new voting rules for Jakarta
Posted by Phil Steitz <ph...@steitz.com>.
Robert Leland wrote:
> Phil Steitz wrote:
>
>> Noel J. Bergman wrote:
>>
>>>> It seems odd to me that code changes effectively require consensus,
>>>> but a release would not. What am I missing here?
>>>
>>>
>>>
>>>
>>> All code in CVS is already there on consensus.
>>
>>
>>
>> As are the bugs ;-)
>>
>> Seriously, this seems like sort of a grey area between "technical,
>> code-related" (so needing consensus) and "policy." The decision to
>> cut a release has technical implications (e.g. backward
>> compatability), but it is not a technical decision per se. I am not
>> pushing for this, just trying to understand better how we look at
>> releases.
>
>
> There are two schools.
> For Struts 0.5, 1.0 , 1.1 we used the criteria that all bugs had to
> fixed or marked as later.
> As a result between 0.5 and 1.0 took 12 months
> and between 1.0 and 1.1 took 20 months.
>
>
> For Struts 1.2 we agreed to switch to the x.y.z
>
> style that Apache HTTPD and Tomcat are using, where you post the bits and
> then call for a vote on stability (alpha/beta/general availability).
> A release can also be withdrawn.
>
> After a release there is often a flood of new users, and a few, usually
> very few new bug reported.
> More importantly there are improvements new users make and hopefully share
> as they tinker with and extend Struts to make it fit their needs. It's
> this synergy that is good for the project.
>
> We tried it the other way first and while we were always making progress
> on the software,
> the development could have easily stagnated. Between Struts 1.0 and 1.1
> we were fortunate enough
> to vote in about 8 committers, each gave the software development a much
> needed boost.
>
> By releasing more often we hope to actually increase the quality, by the
> fact of greater participation
> from the app developers. It's easier to do this now in Struts since
> presently it is in an evolutionary mode.
>
> Also I would say that Tomcat and HTTPD are two of the most successful
> projects Apache has
> so they have to be doing something right.
>
Thanks for the perspective, Robert.
Does this mean you are in favor of having release votes just require
majority approval?
After re-reading http://jakarta.apache.org/site/decisions.html carefully,
I am in favor of keeping things as stated there -- Release Plans require
lazy majority, but Release Testing just requires majority approval.
Phil
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org