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
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]
[License] for jars in CVS
Can we really store non Apache licensed jars in the CVS ? My personal preference is to store no jars in CVS For Example I noticed ognl stored in Tapestry CVS : //-- //Copyright (c) 2002, Drew Davidson and Luke Blanshard // All rights reserved. // //Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions are // met: // //Redistributions of source code must retain the above copyright notice, // this list of conditions and the following disclaimer. //Redistributions in binary form must reproduce the above copyright // notice, this list of conditions and the following disclaimer in the // documentation and/or other materials provided with the distribution. //Neither the name of the Drew Davidson nor the names of its contributors // may be used to endorse or promote products derived from this software // without specific prior written permission. // //THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, // BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS // OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED // AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, // OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF // THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH // DAMAGE. // - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java@apache
Henri Yandell wrote: (I need to get a real sleep schedule) http://www.apache.org/~bayard/japache/ is a list of all Java projects at Apache that I found. Am just pondering ways in which to display all of them on one site, and thought I'd share. This is good. Since there is no single right way to display the wed page you could offer to let users chnage the grouping by using a tab/ or maybe a menu to the left side like, the XML projects do. Hen - 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]
Re: [PROPOSAL] Proactively encourage TLP status
-1 My knee jerk reaction to Proactively encourage TLP status is the same as I had to one of my conservative friend who set out to convert a family of another religion to their true religion. That is repugnant to me, and so is Proactively encourage TLP status If you want to make the information available in a well documented fashion on how to go TLP then +1. For example I am happy where Struts is now, in Jakarta. If Martin Ted want to expend energy making it a TLP I won't -1 it but would -0 it if that was a voting option. For Jakarta Commons I would Strongly -1, to pull out major components like collections. The Jakarta Commons works. It is absolutely one of the most vibrant communities around. As one of the growing number of new PMC members, I want to focus on IP/Licensing matters. I understand that TLP changes what we take responsibility of for Jakarta PMC, but to me it is just one more distraction I don't need right now. I'll take each project that wants to go TLP case by case, its their right to do that, but hope that they think long and hard about it. -Rob Stephen Colebourne wrote: There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. Background info: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges Stephen PROPOSAL The Jakarta PMC shall proactively encourage subprojects to reach Top Level Project (TLP) status. It shall do this by - drawing up a list of advantages that TLP status brings - explaining the effect of the ASF only recognizing Jakarta on a subproject's rights - documenting the process, by receiving advice from recent new TLPs - produce a draft template board resolution for creating a TLP - clearly identifying board meeting dates for TLP creation - proactively encouraging proposal then vote on developer lists - setting a timefame of 3 months for the votes In order to respect current reality, voters on each dev list shall be those of committer and PMC member status who have made recent contributions, with the exact list to be determined by the dev list. - 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]
