[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: [License] for jars in CVS
As I just happened to notice this on Incubator [AltRMI in fact]: Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? The below is, to my quick glance, a BSD licence, so approved. I'm with you on the no jars in CVS, but each to community to their own. Whether Tapestry is properly fulfilling the licence by listing their use of ognl in their documentation would be something to check on. Hen On Wed, 24 Dec 2003, Robert Leland wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
java@apache
(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. Hen - 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: [License] for jars in CVS
In jakarta-tapestry/lib/ext lives all of the licenses of the embedded 3rd party libraries. In that directory is a LICENSE.ognl.txt which contains the full license. I believe this is all that is needed to satisfy the license to redistribute the binary version. I can assure that you we will never ever have a problem with OGNL (Drew is a good friend of mine, and having the high profile use of OGNL in Tapestry and other projects like WebWork2 is great advertising for him and his genius). As for the larger issue of no JARs in CVS - I disagree. I'm pragmatic and also like to have everything in CVS needed to build a distribution (even Ant itself for my employers projects). It saves a lot of hassle to version all source code and dependencies together. Yes, we could make the Maven repository argument, but I personally prefer the complete offline usability of a CVS snapshot. When Tapestry came to Jakarta, it's dependencies were vetted extensively and several were removed from CVS - so it is still a PITA to build Tapestry from CVS (and according to Howard, his attempts to Mavenize the build have been unsuccessful to date). Erik On Dec 24, 2003, at 3:47 AM, Henri Yandell wrote: As I just happened to notice this on Incubator [AltRMI in fact]: Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? The below is, to my quick glance, a BSD licence, so approved. I'm with you on the no jars in CVS, but each to community to their own. Whether Tapestry is properly fulfilling the licence by listing their use of ognl in their documentation would be something to check on. Hen On Wed, 24 Dec 2003, Robert Leland wrote: 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] - 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: [VOTE] ORO 2.0.8 maintenance release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El miércoles, 24 dici, 2003, a las 02:39 Europe/Madrid, Daniel F. Savarese escribió: [X] +1 I approve the release of jakarta-oro version 2.0.8. [ ] -1 I do not approve the release of jakarta-oro version 2.0.8. +1 From here. Just another binding +1 missing. Regards, Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD4DBQE/6VWGZAeG2a2/nhoRAnvwAKCHwrXZAo4jBCdjO8ExFFbv1fiNIQCY3DEF qm4zHx0lyMLKeCZmoJZ2nA== =MvOg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] ORO 2.0.8 maintenance release
On Dec 23, 2003, at 5:39 PM, Daniel F. Savarese wrote: I know now may not be the best time to have a vote, but I would ask the PMC to vote on approving the release of jakarta-oro 2.0.8. The current code base contains important bug fixes and has gone too long without a public release. [ ] +1 I approve the release of jakarta-oro version 2.0.8. [ ] -1 I do not approve the release of jakarta-oro version 2.0.8. + 1 Scott Sanders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
My complaint is this: Our current base of committers were led to believe they have binding votes. We are now told this is not the case. The committers we now have were all elected on the premise that they had binding votes and oversight responsibilities for their codebase. They were in fact elected as if they were to be members of the PMC. Personally, I feel it is an abomination to think we have the right to hand-pick a subset of these committers and bestow upon them binding votes. Our communities deserve to be represented by the set of committers that they have already chosen, not an arbitrary subset deemed to be PMC material. I call for the Jakarta Chair, as the ASF Vice President in charge of Jakarta, to do the Right Thing and promote all Jakarta committers to the Jakarta Project Managemenet Committee. Anything less breaks the covenant we made with each and every Jakarta committer, as published in the original Jakarta guidelines. We said committers had binding votes, and it is now our obligation to make it so. If we fail to make a good faith effort to correct our oversight, then we will have accepted all these contributions under false pretenses. If all committers are PMC members, then all committers can then be subscribed to the PMC list. Each subproject can be given the responsibility of submitting to the PMC list a regular report as to their status. Routine business can be conducted in the subproject DEV list by the PMC members associated with that subproject. In the event there is an unreported oversight issue, any Jakarta Committer/PMC member will be able to bring it up on the PMC list at will. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
On Dec 24, 2003, at 6:28 AM, Ted Husted wrote: My complaint is this: Our current base of committers were led to believe they have binding votes. We are now told this is not the case. The committers we now have were all elected on the premise that they had binding votes and oversight responsibilities for their codebase. They were in fact elected as if they were to be members of the PMC. Personally, I feel it is an abomination to think we have the right to hand-pick a subset of these committers and bestow upon them binding votes. Our communities deserve to be represented by the set of committers that they have already chosen, not an arbitrary subset deemed to be PMC material. I call for the Jakarta Chair, as the ASF Vice President in charge of Jakarta, to do the Right Thing and promote all Jakarta committers to the Jakarta Project Managemenet Committee. I disagree, and I think you are going a bit far. I call for the Jakarta Chair to let us continue the discussion and keep working towards our solution :) Anything less breaks the covenant we made with each and every Jakarta committer, as published in the original Jakarta guidelines. We said committers had binding votes, and it is now our obligation to make it so. If we fail to make a good faith effort to correct our oversight, then we will have accepted all these contributions under false pretenses. False pretenses means that there is the intent to cheat. I assume you didn't know that, and thus will retract it. What we have said is that the committer has write access to the repository and voting rights allowing them to affect the future, and so far, that's how it worked. I don't remember one complaint to the contrary. We have a community that respects the vote of every committer. Period. The fact that we have a *legal* structure, the ASF as a corporation, that requires the board to know about every corporate activity is what the PMC is for - the board delegates oversight to the PMC. So when a community votes, and that community isn't all on the PMC, then you have a vote which is legally not binding, although totally respected by the community, which becomes a legally-binding vote when the PMC is informed, and the PMC acknowledges it. So while the argument that a vote of committers is not binding legally, it is socially binding, and it becomes a binding legal vote when the PMC approves it, as the PMC is in effect voting by proxy, respecting the decision of the community. That actually is no different than the board representing the wishes of the ASF membership. What we are thus solving is not a community issue, but a legal one. Bringing as many informed, interested people as possible onto the PMC increases oversight, increases communication between the subprojects, and IMO, strengthens community. Right now, we couldn't make a clear case that we have enough PMC representation for all the codebases. I'm assuming the source of this idea of yours was the conversation we had on the PMC list about grandfathering in every committer. While suggesting it originally as I too thought it would be the fast approach to the desired solution, I no longer support the idea of doing it in a blanket maneuver, and here's why : 1) Being on the PMC does imply responsibility. Some people are not interested in that responsibility and just want to commit. I think that should be allowed. Not encouraged, but allowed. 2) Roping everyone into the PMC without ensuring things like CLA and understanding of responsibilities makes the whole thing a farce - we couldn't demonstrate that the chain of oversight from the board to the sub-projects is clear and manageable, because we have no clue who we just asked to represent the ASF in project governance, nor do we have any indication of their interest. Thus, while painful and work intensive, adding people one by one lets us produce a healthy, active PMC rather than simply a redefinition of terms. I hope you can see what I'm trying to say, and hoping you want to help out on the 'work intensive' part :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [License] for jars in CVS
I am with Erik on no JARs in CVS. Unless it is a legal issue, I would certainly like to distribute all JARs with the distribution. It saves a lot of hassle and keeps uncessary traffic out of the user-list. -Harish Erik Hatcher wrote: In jakarta-tapestry/lib/ext lives all of the licenses of the embedded 3rd party libraries. In that directory is a LICENSE.ognl.txt which contains the full license. I believe this is all that is needed to satisfy the license to redistribute the binary version. I can assure that you we will never ever have a problem with OGNL (Drew is a good friend of mine, and having the high profile use of OGNL in Tapestry and other projects like WebWork2 is great advertising for him and his genius). As for the larger issue of no JARs in CVS - I disagree. I'm pragmatic and also like to have everything in CVS needed to build a distribution (even Ant itself for my employers projects). It saves a lot of hassle to version all source code and dependencies together. Yes, we could make the Maven repository argument, but I personally prefer the complete offline usability of a CVS snapshot. When Tapestry came to Jakarta, it's dependencies were vetted extensively and several were removed from CVS - so it is still a PITA to build Tapestry from CVS (and according to Howard, his attempts to Mavenize the build have been unsuccessful to date). Erik On Dec 24, 2003, at 3:47 AM, Henri Yandell wrote: As I just happened to notice this on Incubator [AltRMI in fact]: Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? The below is, to my quick glance, a BSD licence, so approved. I'm with you on the no jars in CVS, but each to community to their own. Whether Tapestry is properly fulfilling the licence by listing their use of ognl in their documentation would be something to check on. Hen On Wed, 24 Dec 2003, Robert Leland wrote: 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
I apologize for not quoting. I'm experiencing technical difficulties and making do the best I can. I meant what I said. We must make an immediate, good faith effort to correct the false and misleading information in the Jakarta guidelines, and give all committers due notice of their true status. Otherwise, there's a point where we cross the line. The PMC does not now nor has it ever affirmed each and every decision made by the committers. It may affirm some of the release votes, but there's a lot that goes into making a release. And, AFAIK, the PMC is not authorized to delegate its decision making to non-members. IMHO, we all thought we had the rights and responsibilities of PMC members in the first place. When each and every of these committers were appointed by a subproject, they had the traditional role of a PMC member in mind. Hence, the proposal is to make all Jakarta committers PMC members, which, I believe, was the underlying intent of the original guidelines, and what we all thought was happening in the first place. I reject the idea that being a PMC member brings additional responsibility. All committers are already responsible for decision-making and oversight. We simply need a mechanism that reminds everyone of our existing responsibilities. If all committers are subscribed to the PMC list, and each subproject is given the explicit responsibility for regular reporting, I sincerely believe we will be able to easily dispatch the oversight issues. All we need is a little infrastructure, and the volunteers will take care of the rest. A long-standing principle at Jakarta has always been that the highest, best votes are the commits. We have always rejected the idea of committers without binding votes. To say now that votes are socially binding but not legally binding is inconsistent with community standards. I am happy that we do have communities that will honor the votes of all its committers, whether they are legally binding or not. But, our legalities should reflect the community standards, which are that a committer is a committer. Obviously, if a committer wants to opt-out and become a developer again, that is their choice. But we should not be second-guessing the communities by opting-in committers to the PMC. The community thought they were good enough to have binding votes and binding vetos: who are we to say different? I've proposed my solution: Promote everyone who doesn't opt-out to the PMC; subscribe all committers to the PMC list; require regular reports from each subproject. AFAIK, the only other option on the table is to continue to nominate committers willy-nilly and hope-against-hope that a few more heartbeats will somehow give the PMC the wisdom to make decisions on the subproject's behalf and the mystic ability to oversee all the codebases. I don't think we need to create a Jakarta elite. I think we need to do what we meant to do in the first place: let the committers make the binding decisions. Accordingly, if a positive consensus develops among the committers regarding the original proposal, we can bring it as a vote in the Jakarta way. Otherwise, I would just let the proposal drop, so that the consensus view can proceed. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Ted, I think we must focus on what we agree on - it seems nobody is against expanding the PMC to include most committers ( or all active committers who don't decline ). I'm not sure I understand Geir's current position, but I think he still agrees we need to include most people. I don't think anyone can argue for excluding some active committers - I'm ok with a wait period ( i.e people who have been active committers for at least N months ), but it has to be a deterministic process. In addition to that, there are other things we need to do - like making sure we have clearly identified people who will prepare the reports for each codebase ( be it moderators, release managers, rotation, drafts or whatever a project wants to do - as long as the result is 2-3 names and a monthly report ). We also need to clearly identify what the board means by oversight ( to be honest - I don't know, I just have a vague idea, haven't seen any official definition :-). Since this oversight is motivated by legal concerns - I think we need a definition understandable by everyone, not just guesses. But doing it all at once is very unlikely to work - with all the strong opinions around jakarta. Divide and conquer - first step is to grow the PMC - IMO you need to simplify your PROPOSAL to make it focused to one point ( instead of solving more problems at once ), and move to VOTE. Costin Ted Husted wrote: I apologize for not quoting. I'm experiencing technical difficulties and making do the best I can. I meant what I said. We must make an immediate, good faith effort to correct the false and misleading information in the Jakarta guidelines, and give all committers due notice of their true status. Otherwise, there's a point where we cross the line. The PMC does not now nor has it ever affirmed each and every decision made by the committers. It may affirm some of the release votes, but there's a lot that goes into making a release. And, AFAIK, the PMC is not authorized to delegate its decision making to non-members. IMHO, we all thought we had the rights and responsibilities of PMC members in the first place. When each and every of these committers were appointed by a subproject, they had the traditional role of a PMC member in mind. Hence, the proposal is to make all Jakarta committers PMC members, which, I believe, was the underlying intent of the original guidelines, and what we all thought was happening in the first place. I reject the idea that being a PMC member brings additional responsibility. All committers are already responsible for decision-making and oversight. We simply need a mechanism that reminds everyone of our existing responsibilities. If all committers are subscribed to the PMC list, and each subproject is given the explicit responsibility for regular reporting, I sincerely believe we will be able to easily dispatch the oversight issues. All we need is a little infrastructure, and the volunteers will take care of the rest. A long-standing principle at Jakarta has always been that the highest, best votes are the commits. We have always rejected the idea of committers without binding votes. To say now that votes are socially binding but not legally binding is inconsistent with community standards. I am happy that we do have communities that will honor the votes of all its committers, whether they are legally binding or not. But, our legalities should reflect the community standards, which are that a committer is a committer. Obviously, if a committer wants to opt-out and become a developer again, that is their choice. But we should not be second-guessing the communities by opting-in committers to the PMC. The community thought they were good enough to have binding votes and binding vetos: who are we to say different? I've proposed my solution: Promote everyone who doesn't opt-out to the PMC; subscribe all committers to the PMC list; require regular reports from each subproject. AFAIK, the only other option on the table is to continue to nominate committers willy-nilly and hope-against-hope that a few more heartbeats will somehow give the PMC the wisdom to make decisions on the subproject's behalf and the mystic ability to oversee all the codebases. I don't think we need to create a Jakarta elite. I think we need to do what we meant to do in the first place: let the committers make the binding decisions. Accordingly, if a positive consensus develops among the committers regarding the original proposal, we can bring it as a vote in the Jakarta way. Otherwise, I would just let the proposal drop, so that the consensus view can proceed. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] ORO 2.0.8 maintenance release
Quoting Daniel F. Savarese [EMAIL PROTECTED]: I know now may not be the best time to have a vote, but I would ask the PMC to vote on approving the release of jakarta-oro 2.0.8. The current code base contains important bug fixes and has gone too long without a public release. [X] +1 I approve the release of jakarta-oro version 2.0.8. [ ] -1 I do not approve the release of jakarta-oro version 2.0.8. Craig McClanahan (as Jakarta PMC member) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
(Again, sorry about the quoting.) o·ver·sight 1. An unintentional omission or mistake. 2. Watchful care or management; supervision http://dictionary.reference.com/search?q=oversight The board expects PMCs to exercise (2) so as to avoid (1). :) For a PMC this boils down to issues of committer consensus and intellectual property. In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions). IMHO, if we were to * require subprojects to file regular reports with bullets regarding consensus and oversight, and * subscribe all committers to the PMC list where these reports are filed then we'd be able to defuse these happenstances before they turn into incidents. IMHO, the one and only set of individuals that can provide watchful care over a codebase is the set of committers we already have for each subproject. IMHO, each and every committer to a Jakarta subproject has already passed through a gauntlet that proves they are PMC material and entitled to binding votes. All we need to do is complete the process that promotes our committers to PMC members with binding votes, as our original guidelines contemplated, and require subprojects to provide regular status reports. (Just as the board requires our project to report.) As both Roy and Greg have said, if the Jakarta committers truly understood how few rights and privileges they have, they would be demanding both ASF and PMC membership. Few do, so few have. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Post a list of projects and get PMC people to volunteer to post reports, chase up CLAs and improve PMC-to-non-PMC ratio, and record who has volunteered. Keep going until all projects are covered by the minimum number, which can be 1 to start with. Hen On Wed, 24 Dec 2003, Ted Husted wrote: (Again, sorry about the quoting.) o·ver·sight 1. An unintentional omission or mistake. 2. Watchful care or management; supervision http://dictionary.reference.com/search?q=oversight The board expects PMCs to exercise (2) so as to avoid (1). :) For a PMC this boils down to issues of committer consensus and intellectual property. In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions). IMHO, if we were to * require subprojects to file regular reports with bullets regarding consensus and oversight, and * subscribe all committers to the PMC list where these reports are filed then we'd be able to defuse these happenstances before they turn into incidents. IMHO, the one and only set of individuals that can provide watchful care over a codebase is the set of committers we already have for each subproject. IMHO, each and every committer to a Jakarta subproject has already passed through a gauntlet that proves they are PMC material and entitled to binding votes. All we need to do is complete the process that promotes our committers to PMC members with binding votes, as our original guidelines contemplated, and require subprojects to provide regular status reports. (Just as the board requires our project to report.) As both Roy and Greg have said, if the Jakarta committers truly understood how few rights and privileges they have, they would be demanding both ASF and PMC membership. Few do, so few have. -Ted. - 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: [License] for jars in CVS
Erik As for the larger issue of no JARs in CVS - I disagree. I don't believe that there is room for opinion on this, the fact is it is possible for people to download jars using viewcvs without having read the licence therefore it is not acceptable. UNLESS you have *specific* dispensation from the licensor to do this for your project. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [License] for jars in CVS
I am with Erik on no JARs in CVS. Unless it is a legal issue, I would certainly like to distribute all JARs with the distribution. In the case of most of the licences we'd be likely to consider in this context it is usually perfectly OK to distribute Jars in a distribution because that gives you the opportunity to comply with licence conditions regarding distribution of their licence and other materials. The problem boils down to the fact that some licences, and I know that JavaMail and Activation are cases of this, do allow re-distribution as part of a complete product, but don't allow re-distribution in any other case. Similarly OS licences require that a copy of the licence be distributed along with the binary, and simply placing both in cvs doesn't compel anyone to download or read the licence. As far as OGNL is concerned, from my lurking on the Tapestry lists I'd say that it is pretty clear that there is a close association between the projects, and if you want to continue to have OGNL in cvs I'd get Drew to send a mail to the Tapestry dev list, or the PMC confirming that they are happy for this to happen. FWIW on a previous occasion that this subject came up I got a similar assurance from Mark Mathews regarding the mm.mysql jdbc drivers, he was quite happy with the way we were doing things and this seemed to be acceptable. Leastways no-one here complained. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] As it ever were
As both Roy and Greg have said, if the Jakarta committers truly understood how few rights and privileges they have, they would be demanding both ASF and PMC membership. Few do, so few have. Well I kind of asked for PMC nomination, are you saying that we should, or indeed could, ask for membership? d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] ORO 2.0.8 maintenance release
Quoting Gary Gregory [EMAIL PROTECTED]: -Original Message- From: Daniel F. Savarese [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 17:40 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [VOTE] ORO 2.0.8 maintenance release [X] +1 I approve the release of jakarta-oro version 2.0.8. [ ] -1 I do not approve the release of jakarta-oro version 2.0.8. Gary Gregory (in a pending state, awaiting adding to the committee file) Do you mean you're awaiting commit karma on the jakarta-oro repository? If so, cnan you (or anyone) point me to a vote thread electing Gary as a committer? With that I can add you immediately. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [License] for jars in CVS
I see what you are saying, but why is this an issue only with OGNL? Is it because of license incompatibilities? 'Cause there are other jars in CVS both Apache and non-Apache. -Harish Danny Angus wrote: I am with Erik on no JARs in CVS. Unless it is a legal issue, I would certainly like to distribute all JARs with the distribution. In the case of most of the licences we'd be likely to consider in this context it is usually perfectly OK to distribute Jars in a distribution because that gives you the opportunity to comply with licence conditions regarding distribution of their licence and other materials. The problem boils down to the fact that some licences, and I know that JavaMail and Activation are cases of this, do allow re-distribution as part of a complete product, but don't allow re-distribution in any other case. Similarly OS licences require that a copy of the licence be distributed along with the binary, and simply placing both in cvs doesn't compel anyone to download or read the licence. As far as OGNL is concerned, from my lurking on the Tapestry lists I'd say that it is pretty clear that there is a close association between the projects, and if you want to continue to have OGNL in cvs I'd get Drew to send a mail to the Tapestry dev list, or the PMC confirming that they are happy for this to happen. FWIW on a previous occasion that this subject came up I got a similar assurance from Mark Mathews regarding the mm.mysql jdbc drivers, he was quite happy with the way we were doing things and this seemed to be acceptable. Leastways no-one here complained. d. - 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: java@apache
Robert Leland wrote: Henri Yandell wrote: 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 [perhaps] you could offer to let users chnage the grouping Or perhaps the data could be put into a well-defined format, and let projects repurpose the data as they desire. This could be interesting, Henri. If we had an formal description of a project, providing its name, resource (www, scm, wiki, etc.) locations, ontological classifications, etc., I imagine that could be useful in producing a portal. We would want some nice means for aggregating and dynamically managing the data, but fortunately we have a ready standard for dealing with the content: LDAP. Could be a seriously cool little project. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Ted Husted wrote: (Again, sorry about the quoting.) o·ver·sight 1. An unintentional omission or mistake. 2. Watchful care or management; supervision http://dictionary.reference.com/search?q=oversight The board expects PMCs to exercise (2) so as to avoid (1). :) For a PMC this boils down to issues of committer consensus and intellectual property. In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions) IMHO, if we were to * require subprojects to file regular reports with bullets regarding consensus and oversight, and * subscribe all committers to the PMC list where these reports are filed then we'd be able to defuse these happenstances before they turn into incidents. Thanks for directly addressing the oversight issue. This looks like a good plan to me. Can you explain a little more a) what kinds of issues we need to worry most about; b) what kinds of things should go into the reports; and c) how subproject committers could share the responsibility of creating the reports. IMHO, the one and only set of individuals that can provide watchful care over a codebase is the set of committers we already have for each subproject. I agree. IMHO, each and every committer to a Jakarta subproject has already passed through a gauntlet that proves they are PMC material and entitled to binding votes. Until I understand fully what the responsibilities are, I am not sure that I agree with this, partly because subproject committers may not have signed up for a role beyond the subproject. I agree with your statements about votes being binding, however, so we clearly need to change (or legalize ;) something. All we need to do is complete the process that promotes our committers to PMC members with binding votes, as our original guidelines contemplated, and require subprojects to provide regular status reports. (Just as the board requires our project to report.) This will solve the problem of committers having binding votes on the codebase that they work on, but it may not be the best solution for the Jakarta PMC. Is it totally out of bounds from the ASF perspective to allow subproject committers to have binding votes for their subprojects without being PMC members? I know that this has been discussed and categorical statements have been made, but I frankly do not get it. If the Jakarta PMC reviews and aggregates all of the subproject reports and includes representation from each of the subprojects, where is the gap in oversight? I don't mean to be argumentative or dense here, but it is very important that we understand clearly what the constraints are (and why these constraints exist, and whether they can be changed as the ASF scales). As both Roy and Greg have said, if the Jakarta committers truly understood how few rights and privileges they have, they would be demanding both ASF and PMC membership. Few do, so few have. IIUC, it is mostly a matter of legal protection, not so much rights and privileges (unless you view indemnification as a right or privilege). Here again, a little more background / facts would be helpful, as well as some indication of what is written in stone and why that is so. Phil -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
