[ANN] Tapestry 3.0 rc1 released
Tapestry 3.0 Release Candidate 1 has been released. -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Tapestry 3.0 rc1 released
Here's the vote and result thread. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=2323 -Harish Martin Cooper wrote: On Wed, 17 Mar 2004, Erik Hatcher wrote: Yes, on the tapestry-dev list at the top of the Votes section here: http://jakarta.apache.org/tapestry/changes.html Are we supposed to get releases approved by the PMC? Well, technically, it is only PMC members who can vote. ;-) However, the working model we are using allows the sub-project committers to make the decision, but the PMC needs to be notified of the vote result, preferably including a link to the vote thread on the project's -dev list. -- Martin Cooper On Mar 17, 2004, at 6:47 PM, [EMAIL PROTECTED] wrote: Was there a vote for it? -- dIon Gillard, Multitask Consulting Harish Krishnaswamy [EMAIL PROTECTED] wrote on 17/03/2004 11:55:38 PM: Tapestry 3.0 Release Candidate 1 has been released. -Harish - 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: [VOTE] HiveMind as a Jakarta sub-project
Geir Magnusson Jr wrote: All Jakarta Community Members : Howard M. Lewis Ship, on behalf of the committers of the HiveMind project in the Jakarta Commons sandbox, has proposed HiveMind as a Jakarta sub-project. The proposal was sent to this list, a copy of which can be found here : http://www.mail-archive.com/[EMAIL PROTECTED]/msg09244.html Please read the proposal and vote, and add any comments you deem appropriate. All Jakarta community members are encouraged to vote, although only the votes of the PMC members are legally binding as per the ASF*. [X] +1 I support this proposal [ ] -1 I don't support this proposal [ ] 0 I abstain from voting for or against this proposal Comments : * If the bit about PMC members having binding votes bothers you, solve the problem by indicating interest in joining the PMC :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: push vs. pull
AFAIK, the only ones that use PUSH model are Barracuda and Echo. -Harish Alejandra Gos wrote: Hi, I would like to know if someone could tell me which one of these two models Push, Pull, Struts follows. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extending the PMC ( was: Re: [PROPOSAL] Proactively encourage TLP status)
Anything happening in this regard? -Harish Costin Manolache wrote: Ted Husted wrote: Right now, the only plan seems to be to nominate committers one-by-one on the PMC list. I'm just saying that we shouldn't play favorites. I believe all Jakarta committers have already earned membership in the PMC; we should tender the offer to every Jakarta committer and let each decision-maker decide for himself or herself. If the consensus is that the bootstrap PMC will continue to hand-pick which of our duly-elected committers are promoted to the PMC, and which are not, then so be it. But, personally, I think that process is nothing but busy work. The community has already decided. Let's ratify the community's decisions and let Jakarta be whatever Jakarta wants to be. +1 It seems this is the consensus, to add most committers - one by one or ten by ten. Let's go with that for now, almost everyone is agreeing with the goal of having everyone who cares included ( I didn't see a vote yet, but it seems pretty clear we agree on this ). I don't like the process of hand-picking either - unfortunatly that's the norm in ASF ( membership and all other PMCs use the same mechanism). I hope after we get past the first stage we can have a [VOTE] and change this to people _volunteering_ for PMC - by sending a mail with subscribe subject and the list of sub-projects the person is volunteering to monitor. IMO the only way out of this discussion is to divide the problem into very small pieces and have real VOTEs and counting of each of them. Proposals with more than 1 atom have no chance, and most of the problems occur because everyone seems to think he knows what the others think without asking. Please people, write down what you want, separate it in very elementary pieces, then post a VOTE and see what the majority things ( it may be consensus or a simple majority - but at least you'll know what other think ). Like: 1. Extend the PMC: - to include all committers ( even if the don't want ) - to include all the comitters who want - to include all who want and prove they understand the rules 2. Future extension of the PMC: - hand-picking by current people - people volunteering - because we trust them already to write the code and do the work, and it's fair to let them join whenver they want. 3. Jakarta and TLPs - 'encourage' every subproject to TLP - let each subproject decide if they want to leave jakarta- without encouragements - 'encourage' only subprojects that have problems - do a selection based on some characteristic ( like projects that fit togheter - whatever that means) - try to keep jakarta togheter and increase the community ( as jakarta-commons did ). If someone really wants to go - of course let him. 4. Is jakarta a good thing ? - yes, not perfect but we are improving and working better with other jakarta people - no, it's just a mess - yes, other projects should do what jakarta does ! I hate when people keep talking about consensus and argue as if they knew what the consensus was, but we don't have even the most elementary vote to indicate what a majority thinks. And BTW - please make sure that the votes explicitely state that all _committers_ should vote, but only PMC member votes are binding !!! That's why people should volunteer for PMC, however this is about jakarta and comitters are what jakarata means. Costin - 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: Extending the PMC ( was: Re: [PROPOSAL] Proactively encourage TLP status)
Thanks, will results be posted here? -Harish Henri Yandell wrote: A vote is on-going at the moment [ends Sunday] for 20 or so people, but I've not heard of any movement on the plans to increase in a more aggressive way. Hen On Wed, 14 Jan 2004, Harish Krishnaswamy wrote: Anything happening in this regard? -Harish Costin Manolache wrote: Ted Husted wrote: Right now, the only plan seems to be to nominate committers one-by-one on the PMC list. I'm just saying that we shouldn't play favorites. I believe all Jakarta committers have already earned membership in the PMC; we should tender the offer to every Jakarta committer and let each decision-maker decide for himself or herself. If the consensus is that the bootstrap PMC will continue to hand-pick which of our duly-elected committers are promoted to the PMC, and which are not, then so be it. But, personally, I think that process is nothing but busy work. The community has already decided. Let's ratify the community's decisions and let Jakarta be whatever Jakarta wants to be. +1 It seems this is the consensus, to add most committers - one by one or ten by ten. Let's go with that for now, almost everyone is agreeing with the goal of having everyone who cares included ( I didn't see a vote yet, but it seems pretty clear we agree on this ). I don't like the process of hand-picking either - unfortunatly that's the norm in ASF ( membership and all other PMCs use the same mechanism). I hope after we get past the first stage we can have a [VOTE] and change this to people _volunteering_ for PMC - by sending a mail with subscribe subject and the list of sub-projects the person is volunteering to monitor. IMO the only way out of this discussion is to divide the problem into very small pieces and have real VOTEs and counting of each of them. Proposals with more than 1 atom have no chance, and most of the problems occur because everyone seems to think he knows what the others think without asking. Please people, write down what you want, separate it in very elementary pieces, then post a VOTE and see what the majority things ( it may be consensus or a simple majority - but at least you'll know what other think ). Like: 1. Extend the PMC: - to include all committers ( even if the don't want ) - to include all the comitters who want - to include all who want and prove they understand the rules 2. Future extension of the PMC: - hand-picking by current people - people volunteering - because we trust them already to write the code and do the work, and it's fair to let them join whenver they want. 3. Jakarta and TLPs - 'encourage' every subproject to TLP - let each subproject decide if they want to leave jakarta- without encouragements - 'encourage' only subprojects that have problems - do a selection based on some characteristic ( like projects that fit togheter - whatever that means) - try to keep jakarta togheter and increase the community ( as jakarta-commons did ). If someone really wants to go - of course let him. 4. Is jakarta a good thing ? - yes, not perfect but we are improving and working better with other jakarta people - no, it's just a mess - yes, other projects should do what jakarta does ! I hate when people keep talking about consensus and argue as if they knew what the consensus was, but we don't have even the most elementary vote to indicate what a majority thinks. And BTW - please make sure that the votes explicitely state that all _committers_ should vote, but only PMC member votes are binding !!! That's why people should volunteer for PMC, however this is about jakarta and comitters are what jakarata means. Costin - 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: Extending the PMC ( was: Re: [PROPOSAL] Proactively encourage TLP status)
Thanks for the update. I don't understand why anything but the actual vote needs to be in private. There should probably be a public nomination list with reasons for hand picking (if hand picked) and a public results list with just a tally, like how JCP does it (http://jcp.org/en/whatsnew/elections). Also this process of electing members in batches of 20 or so is time consuming and cumbersome, I think, unless there is a valid reason that this list is not aware of. -Harish Henri Yandell wrote: Currently that doesn't happen. Would be nice if it could, but it just doesn't fit. When someone wins a vote, they're invited to join. If they accept, which they signify by joining the PMC list [the Jakarta Chair moderates it], then the Jakarta Chair passes their name onto the board and they're meant to get inked into the committers/board/committee-info.txt file when it's official. From the previous batch of 20 or so, there are still 3 people or so who I didn't hear back from after two email attempts, and the other 17 [made up numbers] are still not in the committee-info file. I'm unsure when an announcement to this list would/should happen under the process above. The only part that is enforced is the board part, so until someone appears in committee-info, they're not technically on the PMC. There's a /committers/pmc/jakarta/pmc-pending.txt file which shows who is currently waiting addition to the committee-info. Ideas? Hen On Wed, 14 Jan 2004, Harish Krishnaswamy wrote: Thanks, will results be posted here? -Harish Henri Yandell wrote: A vote is on-going at the moment [ends Sunday] for 20 or so people, but I've not heard of any movement on the plans to increase in a more aggressive way. Hen On Wed, 14 Jan 2004, Harish Krishnaswamy wrote: Anything happening in this regard? -Harish Costin Manolache wrote: Ted Husted wrote: Right now, the only plan seems to be to nominate committers one-by-one on the PMC list. I'm just saying that we shouldn't play favorites. I believe all Jakarta committers have already earned membership in the PMC; we should tender the offer to every Jakarta committer and let each decision-maker decide for himself or herself. If the consensus is that the bootstrap PMC will continue to hand-pick which of our duly-elected committers are promoted to the PMC, and which are not, then so be it. But, personally, I think that process is nothing but busy work. The community has already decided. Let's ratify the community's decisions and let Jakarta be whatever Jakarta wants to be. +1 It seems this is the consensus, to add most committers - one by one or ten by ten. Let's go with that for now, almost everyone is agreeing with the goal of having everyone who cares included ( I didn't see a vote yet, but it seems pretty clear we agree on this ). I don't like the process of hand-picking either - unfortunatly that's the norm in ASF ( membership and all other PMCs use the same mechanism). I hope after we get past the first stage we can have a [VOTE] and change this to people _volunteering_ for PMC - by sending a mail with subscribe subject and the list of sub-projects the person is volunteering to monitor. IMO the only way out of this discussion is to divide the problem into very small pieces and have real VOTEs and counting of each of them. Proposals with more than 1 atom have no chance, and most of the problems occur because everyone seems to think he knows what the others think without asking. Please people, write down what you want, separate it in very elementary pieces, then post a VOTE and see what the majority things ( it may be consensus or a simple majority - but at least you'll know what other think ). Like: 1. Extend the PMC: - to include all committers ( even if the don't want ) - to include all the comitters who want - to include all who want and prove they understand the rules 2. Future extension of the PMC: - hand-picking by current people - people volunteering - because we trust them already to write the code and do the work, and it's fair to let them join whenver they want. 3. Jakarta and TLPs - 'encourage' every subproject to TLP - let each subproject decide if they want to leave jakarta- without encouragements - 'encourage' only subprojects that have problems - do a selection based on some characteristic ( like projects that fit togheter - whatever that means) - try to keep jakarta togheter and increase the community ( as jakarta-commons did ). If someone really wants to go - of course let him. 4. Is jakarta a good thing ? - yes, not perfect but we are improving and working better with other jakarta people - no, it's just a mess - yes, other projects should do what jakarta does ! I hate when people keep talking about consensus and argue as if they knew what the consensus was, but we don't have even the most elementary vote to indicate what a majority thinks. And BTW - please make sure that the votes explicitely state that all _committers_ should vote, but only
Re: [PROPOSAL] Proactively encourage TLP status
Geir Magnusson Jr. wrote: On Dec 30, 2003, at 8:37 PM, Harish Krishnaswamy wrote: Martin Cooper wrote: This doesn't seem quite right to me. I agree that when we have voted in a new committer, both the existing committers and the new committer have had the same expectations with respect to their rights and responsibilities *within the sub-project*. While those rights and responsibilities may be the same ones that apply to members of the PMC, the domain over which they apply is very different. I don't think it would be right to turn around now, and tell a committer on sub-project X oh, by the way, you're now part of the PMC and that means that you are (collectively) responsible for all of Jakarta. That doesn't meet the expectations *I* originally had at all, when I first became a Jakarta committer myself. Yes, but I thought I had a say, by way of binding votes, in the project I was elected in, and was responsible for the future of the project and now that doesn't seem true either. I haven't been around for too long but this whole thing seems like a problem of misunderstanding of rights and responsibilities. Not that I have a good understanding :) I think one of the disconnects here is that what we are trying to do is fix an organizational problem to solve a legal issue in order that the legal organization reflects the non-legal reality. Let me try to clarify that babble with a question : Forgetting about this recent thread of conversation, do you feel that you aren't responsible for and able to affect the future of the projects you are involved in? I believe and hope the answer is, without thought, no. Yes, absolutely no. My point was, the understanding of committer rights (legally that is), at the time of becoming a committer, was incorrect and so it doesn't matter what we thought or expected. We will just have to make things legally right and realign our expectations accordingly, I think. The non-legal reality is that you and your community have been working building software, judging commits, electing new committers, etc. Without disturbing anything [as best we can], we want to make things conform to the corporate governance requirements of the ASF. Absolutely, I totally understand and agree. It seems that oversight is the only extra responsibility of a PMC member, and it seems oversight is about making sure that contributed code conforms to IP rights. If so, may be somebody has to explain why the CLA is not good enough to ensure the acceptance of this responsibility. That's an important one, yes. The CLA declares that *you* the committer, to the best of your knowledge, blah, blah... which is one side of the issue. The other side is that 'we the ASF' are also looking out for the ASF re IP rights. So the ASF is able to say 1) we actively are examining IP via the PMC and 2) we require our committers 'examine' IP and certify cleanliness via the CLA. This strengthens the ASF's position that it does everything reasonable. But another aspect of PMC participation is simply legal detail. As Roy put it (and I'm probably going to bungle this), binding actions of the ASF happen through the structure of the board, officers and the PMCs. Only votes from people on the PMC list are [legally] recognized. Now, I'm not in any way minimizing the necessity for legal compliance, but I also want to emphasize that recognized by the community is just as important, as we'd all just leave and do things elsewhere if it were otherwise. Absolutely, I totally understand and agree. I think Ted's proposal is not forcing all committers to become PMC members but rather extending the membership to every one of them and gives them an option to opt out. I don't think there should be any criteria, other than the willingness of the committer, to become a PMC member. This proposal fulfills that and makes the process faster, I think. While it would make the process faster, I think that the validity of the desired endpoint, a PMC that covers all subprojects well, is path dependent, and the path to greatest defendable legitimacy is when we just don't glom everyone onto the PMC, but ensure that those on it are interested (which the 'opt out' above covers), know what they are doing (via simple educational support) and most importantly, are aligned with the ASF. After all, this *is* a committee of the board of the ASF. Absolutely, I totally understand and agree. This seems in accordance with Ted's proposal as far as PMC membership is concerned. -Harish geir -Harish PS. I think my thoughts follow the right[eous] path ;) Foisting additional responsibility on committers doesn't seem like the right way to go, to me. Allowing - even encouraging - them to take on the additional responibilities of a PMC member would fit much better with *my* original expectations, at least. -- Martin Cooper I believe from the ASF perspective committing==voting and committing
Re: [PROPOSAL] Proactively encourage TLP status
Martin Cooper wrote: On Tue, 30 Dec 2003, Ted Husted wrote: - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 16:05:11 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ I never understand why you keep doing this. There is no 'schism' between the PMC and the community, and no one is proposing it. I hate to appeal to authority because the ASF charter does provide a healthy bit of freedom for any given PMC, but for example, if we want to follow the model of the httpd project, from which the ASF bylaws were fashioned, and I know you are a vocal proponent of the 'ASF Way', it is my understanding they invite committers onto the PMC after some time after receiving committership when it's clear that is appropriate for that person. Committing != oversight. There are people who are committers that may not wish to participate on the PMC. We want everyone to, but if they aren't *interested* in doing it, putting them on the PMC achieves nothing, and actually, IMO, weakens the PMC. There are all sorts of valid reasons to not want to be on the PMC, I suppose, and we should never stop inviting that person. 100% should be the goal, not the requirement. The schism is that the PMC did not elect our committers. In the normal course, the body that elects the committers also decides which committers (or other interested parties) merit inclusion in the PMC. However, Jakarta has not done things in the normal course. The PMC did not select most of the committers: the subproject communities did. And when our community selected the committers they expected that these individuals would be the ones actively managing the codebase. The community expected these individuals to have the rights and responsibilities we now abscribe only to the PMC. This doesn't seem quite right to me. I agree that when we have voted in a new committer, both the existing committers and the new committer have had the same expectations with respect to their rights and responsibilities *within the sub-project*. While those rights and responsibilities may be the same ones that apply to members of the PMC, the domain over which they apply is very different. I don't think it would be right to turn around now, and tell a committer on sub-project X oh, by the way, you're now part of the PMC and that means that you are (collectively) responsible for all of Jakarta. That doesn't meet the expectations *I* originally had at all, when I first became a Jakarta committer myself. Yes, but I thought I had a say, by way of binding votes, in the project I was elected in, and was responsible for the future of the project and now that doesn't seem true either. I haven't been around for too long but this whole thing seems like a problem of misunderstanding of rights and responsibilities. Not that I have a good understanding :) It seems that oversight is the only extra responsibility of a PMC member, and it seems oversight is about making sure that contributed code conforms to IP rights. If so, may be somebody has to explain why the CLA is not good enough to ensure the acceptance of this responsibility. I think Ted's proposal is not forcing all committers to become PMC members but rather extending the membership to every one of them and gives them an option to opt out. I don't think there should be any criteria, other than the willingness of the committer, to become a PMC member. This proposal fulfills that and makes the process faster, I think. -Harish PS. I think my thoughts follow the right[eous] path ;) Foisting additional responsibility on committers doesn't seem like the right way to go, to me. Allowing - even encouraging - them to take on the additional responibilities of a PMC member would fit much better with *my* original expectations, at least. -- Martin Cooper I believe from the ASF perspective committing==voting and committing==oversight Every time a committer commits, they vote for the code they commit. Most often, it a vote subject to lazy consensus, and in rare cases it might not be binding. But, it is vote nonetheless. Every time a committer commits, they either donate code to the ASF or facilitate a donation, and they incur the obligation to ensure, to the best of their ability, that this is IP that can be donated to the ASF. If we have a committer that does not accept these obligations, then a misunderstanding has occurred, and such committers should step down. The ASF does not grant write-access lightly. I think people understand that. In the normal course, virtually all ASF committers are PMC members, because its the committers make the decisions and do the work. It is true that on occasion an ASF committer will not yet be member of the project PMC. Their votes may not be binding, and their commits will be scrutinized by PMC members (which is to say other members of the
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: [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: Jakarta: Confederation or Single Project?
Thanks Craig, this is elaborate, informative and puts the issue in my perspective. May be this should be put on the website too somewhere. Here are my inferences so far... inferences ASF is a group of projects administered by the Apache board members. The board delegates certain responsibilities over to the PMCs of the individual projects while still maintaining the authority and management responsibilities. The PMC is responsible for a wholesome code and community of the project it oversees but does not have the authority to recognize new projects. Jakarta started out as a single project for a web container and has grown into a foundation of projects in itself without sufficient administration/organization. /inferences Here are my thoughts distilled from a lot others'... * I think the projects at ASF should be classified in some way (preferably by technology like we have now for xml, db etc.) into umbrella projects. All projects piled together at the top level would not convey very well. This is where Jakarta would need redefinition. Seems like the inital motivation, server side web development, is a good fit. And that would mean some reshuffling. * I think each umbrella project or each project within could have a PMC and each project should maintain a PMC membership of atleast 51% of its committers to sustain. * I think the website should match the organizational structure to avoid confusion. * I think the board should classify the newly adopted projects. Projects that churn out of existing projects should be brought back to the board for classification at the time of creating new CVS repositories. * Each umbrella could have a commons and a sandbox to share and play. * There could be a top level commons to house cross-umbrella components. It seems like what we now have is pretty much in good shape and only means that the following actions take place... * Reorganize Jakarta (and may be others??) * Enforce project level PMC membership Just my thoughts. Regards, Harish Craig R. McClanahan wrote: Quoting Harish Krishnaswamy [EMAIL PROTECTED]: Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish These comments are going to be (like anyone's would be) colored by my own personal experiences during the development of Jakarta -- including my ignorance of a lot of the details in subprojects that I'm not an active participant. But it should give you a little feel for the history of the place. The gist of the creation of Jakarta was around three facts: * Apache wasn't an incorporated entity (this is about four years ago now), but wanted to be -- and was formally becoming the Apache Software Foundation. * Apache had a project to build a servlet container (Apache JServ) at a website called java.apache.org which created a trademark-use issue around java. (I was a committer on Apache JServ, which is how I originally got involved in open source software.) * Sun wanted to contribute, and Apache wanted to accept, the source code for the servlet and JSP implementation called the Java Servlet Development Kit, and later published by Apache as Tomcat 3.0. Just as an item of slight historical interest, Jakarta was the name of the conference room at Sun where a lot of the early discussions took place. An organizational framework to focus on developing open source server side Java stuff was created to host these initiatives, and other related subprojects got proposed and added to the mix. As the number of Jakarta committers scaled from the original 10 or so to where we are today (hundreds), the original charter has become, umm, somewhat stretched. Ironically, it didn't take long at all for the scope of that original charter to get exceeded, because one of the little nuggets of code that was included in the original Tomcat contribution was a pure-Java build tool (to replace make) called Ant ... As more and more subprojects were added, there were some inevitable cases of overlapping scope, and overlapping implementations of the same ideas. One of the best things we've done (IMHO) was purposely creating a subproject (jakarta-commons) focused on making small, focused, reusable packages, and encouraging the larger projects to use them. Not only has this been successful within Jakarta -- there's been quite a lot of cross-fertilization among the web app frameworks, for example -- it's also created a fairly rich library of funcational packages that are widely used elsewhere. But one could really argue whether something like Commons Digester (originally designed as an easy-to-use tool to parse XML configuration files) really fit the Jakarta charter. Over time, there have been more than a few, err, voluminous discussions about how to scale up Jakarta from an organizational perspective, and whether the fundamental organizing principle was still the correct one
Re: Just in case you're curious
For the record I'm in favour of transacting business HERE. But I would like to respond by saying that as I understand it it is the source and the development of it which is open, not the organisation. As a committer I would like to know what's going on with the origanization. I can understand certain private conversations that involve legal implications, but anything else, I think, should be out in the open to do justice to the committers. It seems like there is some talk going on about the Jakarta banner in private that I have no clue about. I would appreciate the knowledge sharing in such metters. -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
First off, as a commiter your entitled to be proposed for membership of the PMC, which I'd be happy to do. Thanks for the offer but I don't know if I would qualify for one. The description on the website is pretty broad. Secondly there has been a long drawn out debate in numerous places (including here) about the future direction of Jakarta, recently there have been threads on the PMC list which raise the issue, but they are mainly just at the My Idea stage. I hope those who have been debating there will raise their issues here, it is important to involve the whole community in this debate as it affects us all. Absolutely, this kind of stuff, I think, belongs here. -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why you *want* to be on the PMC
If the aim of the PMC is to house a vast majority of committers, and if the role of a PMC member is simply to follow some guidelines and regulate development, I don't see the distinction between a PMC member and a committer. If the PMC membership requires legal and governing skills, I am not sure the PMC can attain vast majority. Is there a legal binding between a member and Jakarta/Apache that does not exist between a committer and Apache? I am certainly willing (and want) to share some responsibilities to help grow Jakarta but I want to be clear on the responsibilities I will be taking on as a member and if I will be eligible. Thanks, Harish Noel J. Bergman wrote: Harish Krishnaswamy wrote: First off, as a commiter your entitled to be proposed for membership of the PMC, which I'd be happy to do. Thanks for the offer but I don't know if I would qualify for one. The description on the website is pretty broad. Harish, as I see it, part of the problem comes from a misunderstanding about the nature of the PMC. The term management has been misunderstood in the context of an ASF Project. The intended purpose for the PMC is that the PMC members are the core group making all decisions related to an ASF Project. That includes voting on code changes, voting on new Committers, voting on new PMC members. Not all Committers may be on the PMC, but the majority should be -- and those who aren't do not have binding votes (see explanation below). I recently did a quick survey of some projects: Project # PMC# Committers % HTTP Server:43 59 73% APR 29 43 67% Cocoon 31 67 46% Jakarta 42+ 352 12% Not all Committers are still active, so the ratio of PMC to active Committers is higher, but the difference is still pretty clear. The Jakarta PMC, using the current structure, is missing 100s of members. Now here is where the problem comes in. Although every PMC is free to establish its normal rules, the legal system also plays a part. The structure of the ASF exists to protect us. In order to be protected, decision makers must be PMC members. Decisions include code changes. The discussions taking place on [EMAIL PROTECTED] regarding how to fix the situation take different directions, but I think that everyone agrees that the vast majority of Jakarta Committers must be on a responsible PMC. The question, as I see it, is really about *how* we're going to organize it, not *if*. --- Noel - 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: Why you *want* to be on the PMC
Henri Yandell wrote: On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: If the aim of the PMC is to house a vast majority of committers, and if the role of a PMC member is simply to follow some guidelines and regulate development, I don't see the distinction between a PMC member and a committer. If the PMC membership requires legal and governing skills, I am not sure the PMC can attain vast majority. Is there a legal binding between a member and Jakarta/Apache that does not exist between a committer and Apache? Yep. There is very little legal binding between a committer and Apache, apart from the legal fact that the committer is donating code to Apache. I am sorry if I am being naive, but can it not be enforced that a committer should also be bound the way a member is? That way the responsibilities are borne by every committer and we could have a very small team of members for governance. An Apache Member is a part of the Apache organisation, while a PMC member is recognised by the Apache organisation as being responsible for that TLP. There's no need for them to be an Apache Member however. [IANAL etc, this is how I see it from descriptions people have given] I am certainly willing (and want) to share some responsibilities to help grow Jakarta but I want to be clear on the responsibilities I will be taking on as a member and if I will be eligible. By being an active committer, you are eligible. As for what responsibilities are, attempts to define the role of a PMC member have not gone well so far but will hopefully get there. I am sorry, I meant to say if I would qualify for the responsibilities. 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: Why you *want* to be on the PMC
Ah now it all makes sense :) May be this should be included with the CLA and then there would be no reason to lobby for more members, really. -Harish Noel J. Bergman wrote: I don't see the distinction between a PMC member and a committer. grin You catch on quickly. :-) The difference is that a PMC member, as a normative statement, has a binding vote on the project. By allowing someone to become a Committer, you allow direct contribution to the codebase, but the PMC is overseeing it. The Committer contributes, but does not have a say. So there is a natural progression from: Contributor (patches) - Committer (authorized access) - PMC member If the PMC membership requires legal and governing skills, I am not sure the PMC can attain vast majority. It doesn't. 300+ Committers are already doing most of what they need to do, without the benefit of being on a PMC. Is there a legal binding between a [PMC] member and Jakarta/Apache that does not exist between a committer and Apache? Please see: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] .orgmsgNo=2711. --- Noel - 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]
Volunteering for PMC membership
Hi, I, Harish Krishnaswamy (harishkswamy), a Tapestry committer, would like to help grow Jakarta in whatever capacity I can and I request my nomination for PMC membership. Regards, Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why you *want* to be on the PMC
Geir Magnusson Jr. wrote: On Dec 18, 2003, at 3:08 PM, Harish Krishnaswamy wrote: Ah now it all makes sense :) May be this should be included with the CLA and then there would be no reason to lobby for more members, really. We want to make sure that the PMC members are committers who understand the responsibility and are willing to take it. Automatic inclusion doesn't do that. But it seems that the exact responsibilities is not really laid out and is the primary reason for confusion? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confused with PMCs, TLPs, ASF and Power?
Very nice, this really clarifies the organizational structure and issues at hand. Thanks, Harish Stephen Colebourne wrote: Then try this: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges It aims to be a starter course on why discssions about PMCs, TLPs, Jakarta and the ASF appear, and possibly how they affect you. Be aware of the disclaimer at the top, however trying to distill any controversial topic to one page always ends up annoying someone. Stephen - 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: Jakarta: Confederation or Single Project?
How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) 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: Jakarta: Confederation or Single Project?
That's true, so back to Jakarta = Server side web development! But is it restricted only to Java web development or just plain web development? -Harish Henri Yandell wrote: Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. If we go with this approach, we end up with the continuation of: should digester be in jakarta or xml etc. Does XML take precedence over the fact it's in Java, or does it just depend on which community creates or invites the codebase. As they have to go through the Incubator now [or be fast-tracked with the board's new scheme Greg mentioned], is the community inviting them in as important as it used to be. I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is Java web development, but only indirectly I think, ditto for Avalon]. Hen On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) 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] - 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: Why you *want* to be on the PMC
Henri Yandell wrote: Multiple PMCs is not a problem. There are James, Maven people on the Jakarta PMC etc. The idea below still concerns me. If all the PMC's share the same website, who is responsible for the website as a global concept. For example, the need to do mirrors. If a Jakarta-Site PMC exists, all other PMCs [jakarta sub-project based] are accepting the Jakarta Site PMC's oversight over their websites. Why is this a problem? I think it is good to be that way. How is Apache website handled btw? May be we can follow suit? -Harish Hen On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: From what I have understood today, this seems like a nice option to me to straighten things out. +1 -Harish Dirk Verbeeck wrote: +1 If this is acceptable by the board then it's the ideal solution. No changes to the email/website structure, jakarta remains the center of the apache java development with a shared announcement list, general list, news and download pages, ... The only change is that the board gets a list of members overseeing each project (=PMC) and additionally a Jakarta Community project building a java community at Apache. (assisting the java projects) The board will not get one big report from jakarta but many small ones and can see witch (sub)projects needs more members. Of course many members will be joining multiple PMCs. Is this possible? -- Dirk Noel J. Bergman wrote: There is a difference between a hierarchy and a confederation. There is absolutely nothing that says that we cannot have: Jakarta PMC: responsible for jakarta-site/jakarta-site2 Tomcat PMC: tomcat and related code Struts PMC: struts and related code Jakarta Commons PMC: ... Tapestry PMC: ... ... All without a single change to the Jakarta domain. No one should feel that there is any relationship between the Foundation's legal structure, and e-mail/web addresses. We have had this confirmed already by both Greg and Sam. The above *is* an acceptable solution to the Board. The question is whether or not it is an acceptable one to us. --- Noel - 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: Jakarta: Confederation or Single Project?
I like the idea but does this mean we will be dumping the Jakarta banner? Or will it serve as an incubator for TLPs? The Jakarta banner has earned quite a reputation and would be a shame to dump it. -Harish Stephen Colebourne wrote: Not really (my POV) As people we naturally think in terms of the hierarchy ASF to Jakarta to MySubProject. But the middle layer is artificial. It could just as well be XML or DB or WebApps or Java or C or 'Projects starting with S' or 'Projects where Joe Bloggs works'. There simply is no one way of categorizing, hence there actually is no one community either. (ie. 'the jakarta community' simply does not exist in my eyes) The alternative is a one layer structure ASF to MyProject which gives full oversight, management and confidence both to the ASF and the ASF. Separately, there is a search website that allows searches by all the different ways that you might want to look things up. After all, the one layer (TLP) structure didn't harm Ant or James, and almost certainly benefitted Maven, Avalon and from the looks of it Log4J. In the end, actions will speak louder than words. Stephen - Original Message - From: Harish Krishnaswamy [EMAIL PROTECTED] That's true, so back to Jakarta = Server side web development! But is it restricted only to Java web development or just plain web development? -Harish Henri Yandell wrote: Because it's wrong. XML has lots of Java bits, and Maven, Ant, Cocoon, Avalon, James are all Java Development and not in Jakarta. If we go with this approach, we end up with the continuation of: should digester be in jakarta or xml etc. Does XML take precedence over the fact it's in Java, or does it just depend on which community creates or invites the codebase. As they have to go through the Incubator now [or be fast-tracked with the board's new scheme Greg mentioned], is the community inviting them in as important as it used to be. I'd much rather find a real subtitle for Jakarta that fits well [Cocoon is Java web development, but only indirectly I think, ditto for Avalon]. Hen On Thu, 18 Dec 2003, Harish Krishnaswamy wrote: How about Jakarta = Java Development? Then, they all seem in place, no? -Harish Henri Yandell wrote: On Thu, 18 Dec 2003, Costin Manolache wrote: IMO it would be sad if projects like struts or tapestry leave jakarta - since they are closely related to web development and server side java ( compared with log4j or regexp for example ). So, Jakarta = Server side web development is the subtitle. Log4J, POI, ORO, Regexp, all of Commons except HttpClient, Latka and FileUpload, Gump, BSF, BCEL are the ones that seem most out of place in that they don't focus on that subtitle. Slide would be if a WebDAV TLP were to arrive. Just as a flamebait suggestion :) 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] - 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: Jakarta: Confederation or Single Project?
Could someone please explain the motivation behind the creation of Jakarta and how it got to where it is today? May be that would help answer some of the questions we have? -Harish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
