Re: [PROPOSAL] Agreeing new voting rules for Jakarta
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Agreeing new voting rules for Jakarta
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
