Re: [VOTE] Move Jakarta to the Attic; close down Jakarta PMC
+1 On Nov 11, 2011, at 4:28 AM, Mladen Truk wrote: +1 On 11/10/2011 07:01 PM, Henri Yandell wrote: A joint vote to retire Jakarta into the Attic and to ask the board to close down the PMC. Regards -- ^TM - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org - To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
Re: Jakarta at the center of the (ASF) universe
On Nov 16, 2007, at 3:13 PM, Jukka Zitting wrote: Hi, Earlier today I did some graphs on cross-pollination among Apache projects and blogged a summary at [1]. Jakarta always ended up dominating the graphs, so the version on my blog has Jakarta excluded. Why? W/o Jakarta, the diagrams don't make any sense. For example, the Jakarta-free one has velocity's only relationship to DB (!), and for Harmony, to DB and XML! Ant, arguably one of the most pervasive projects, has no connection to anything else... geir If you're interested, there's a version with Jakarta in it at [2]. :-) [1] http://jukkaz.wordpress.com/2007/11/16/the-apache-cloud/ [2] http://people.apache.org/~jukka/2007/asf5.png BR, Jukka Zitting - 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 at the center of the (ASF) universe
On Nov 18, 2007, at 1:47 PM, Niall Pemberton wrote: On Nov 18, 2007 12:07 PM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Nov 16, 2007, at 3:13 PM, Jukka Zitting wrote: Hi, Earlier today I did some graphs on cross-pollination among Apache projects and blogged a summary at [1]. Jakarta always ended up dominating the graphs, so the version on my blog has Jakarta excluded. Why? W/o Jakarta, the diagrams don't make any sense. For example, the Jakarta-free one has velocity's only relationship to DB (!), and for Harmony, to DB and XML! Ant, arguably one of the most pervasive projects, has no connection to anything else... Ant as a piece of software is pervasive - but are the Ant committers pervasive? I'd guess certainly more than an island. Jukka's cloud shows community/commiter relationships rather than software. The Jakarta one is interesting as it shows so much of JavaLand at the ASF sprang from Jakarta. I agree with Jukka though - it distorts the landscape. But that's the fact - that most of JavaLand sprang from jakarta... geir Niall geir If you're interested, there's a version with Jakarta in it at [2]. :-) [1] http://jukkaz.wordpress.com/2007/11/16/the-apache-cloud/ [2] http://people.apache.org/~jukka/2007/asf5.png BR, Jukka Zitting - 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 at the center of the (ASF) universe
On Nov 18, 2007, at 4:10 PM, Jim Jagielski wrote: On Sun, Nov 18, 2007 at 01:58:29PM -0500, Geir Magnusson Jr. wrote: But that's the fact - that most of JavaLand sprang from jakarta... Jukka's graph shows committer cross-polination, not *codebase* I don't think that anyone confused codebase and committer. I thought that many of the ant committers had much influence in what followed, since ant was one of the early arrivals in Jakarta as it was the build system for tomcat... therefore the linkages are meaningful, IMO. I think that the jakarta node represents meaningful information. For example, Velocity came from core Turbine people, and you can't get any sense of that from the Jakarta-free graph. Maybe that's the problem - that history isn't represented in current committer lists, and thus when you drop Jakarta, information is lost. cross-polination (as I understand it)... So yes, since most committers for most ASF java projects were in Jakarta (since those projects were *in* Jakarta, after all), I still think that the non-Jakarta page provides a more accurate representation of the real dynamics, by removing the artifical aspects of Jakarta. I guess it comes down to what Jukka's trying to show geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds docu?
On Jan 18, 2007, at 8:57 AM, Henri Yandell wrote: On 1/17/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: So how about biting the bullet and installing one of the well established and obviously easier tools: * Cruise Control (http://cruisecontrol.sourceforge.net/) Just downloaded this the other day to sit and play with. When last I looked at it I disregarded it because it insisted on a source only distribution and its source wouldn't build on OS X. They had a new release recently and a binary, so I'm aiming to give that a shot. FWIW, I like it a lot. When I was deciding on a CI system for harmony, I looked at a few and eventually settled on CC, because it had no inherent bias to what you were running, and while a bit rought around the edges, seemed to have lots of nice little features. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A chart/graph Library suite
On Jan 7, 2007, at 8:55 AM, J.Pietschmann wrote: Senthil S wrote: Expecting a chart/graph making library from Apache that is similar to jfreechart and has enhanced features to create live and interactive graphs. The question is: why do you think there should be another charting/graphing library? Do you have problems with the JFreeChart license (LGPL)? Wasn't it a BSD license before? You could go shopping around for other libraries, there are at least 50 open source libs for Java and C# on sourceforge, some using BSD or MIT license. For an ASL licensed library, checv out krysalis wings http://www.krysalis.org/wings/, although the project seems to be dead too. J.Pietschmann - 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: A chart/graph Library suite
On Jan 7, 2007, at 10:58 AM, Martin van den Bemt wrote: Geir Magnusson Jr. wrote: On Jan 7, 2007, at 8:55 AM, J.Pietschmann wrote: Senthil S wrote: Expecting a chart/graph making library from Apache that is similar to jfreechart and has enhanced features to create live and interactive graphs. The question is: why do you think there should be another charting/graphing library? Do you have problems with the JFreeChart license (LGPL)? Wasn't it a BSD license before? Are you confusing it with JChart maybe ? Could be. Was that the one that was BSD licensed and then switched? Mvgr, Martin - 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: offtopic - Woodcrest vs. Xeon
Full disclosure, I work for Intel. :) First, are you sure it's a 2GHz Woodcrest? I thought it would be a 3GHz part. Second, is it two Woodcrest (for 4 cores total) or just 1 Woodcrest? Third, woodcrest is an internal code name, and the parts are sold under the Xeon brand, so which Xeon is a question you want to ask the vendor - it could be woodcrest based as well. Finally, the current world record in spec's JBB2005 benchmark is held by IBM with their JVM on woodcrest (Xeon 5160) at 114k bops/JVM on a 4 core machine... You can go see the results here : http://www.spec.org/jbb2005/results geir Will Glass-Husain wrote: Hi, This is a little off-topic but I thought I'd do a quick poll. I've got an opportunity to reconfigure my multi-server Tomcat/Java setup for a computation-heavy webapp. One vendor is proposing dual process Woodcrest (dual core) 2.0 GHz, the other is promoting dual Xeon 3.2GHz. The Woodcrest's have slower clock speeds but the dual core is supposed to make it faster. Just curious if anyone has experience with the Woodcrest servers - in particular if anyone has benchmarked Sun's JDK on the two processors with a computation heavy app I'd love to hear from them. (Can Sun's JDK make effective use of the multi-processor, multi-core system?) Cheers, WILL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] Move Velocity to TLP
Nathan Bubna wrote: On 9/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Bubna wrote: On 9/22/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: snip I'm +1 and -1. I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not necessary, but not unreasonable. I'm -1 because I'm worried that this is a new kind of umbrella that's planned. Making it a catchall for things that are and use Velocity is going the wrong direction. Nothing new about it. Velocity became just such an umbrella under your leading, or am i mistaken about your part in forming DVSL and VelocityTools? :) Tools was created because we wanted to offer support for struts users, and struts didn't want it. We didn't create a replacement for struts. And yeah, it grew in scope. DVSL was similar. Maybe it could have gone into commons, but again, it was home grown. And Billy did it too! isn't really a good reason to do it :) Agreed. And neither do i think Johnny couldn't do it is really a good reason not too do it. :) I don't understand that argument. You are trying to say no, we're not an umbrella while saying yes, we are, but you did it too. I'm having trouble resolving these two confusing messages. And the idea is not that all Velocity using projects are welcome, but that we are free to invite projects that are explicitly built upon or for Velocity. There are big differences between being free to invite projects and being a catchall and between being a project that uses or supports Velocity and one that is explicitly built for or upon Velocity. How do you draw the line? That's the real question here. I'd love to hear good thoughts and suggestions on this. I wrote/modified the proposal as well as i could, but i would very much appreciate more specific feedback on the wording of the charter-ish stuff in there. Of course, i'm probably explaining my thoughts on this question more clearly in these discussions than i did in that document... So, to summarize, the line should be drawn: - On a case by case basis. - Carefully by the participating members of the Velocity PMC - To the exclusion of projects which simply use or support Velocity, without being explicitly and primarily built for use with the Velocity template engine and/or firmly upon the core Velocity codebase. Sure - there could be a rule that it only works with velocity - IOW, w/o velocity, it doesn't function. Velosurf seems to be a good example of this. - To the exclusion of projects whose developer communities have no lasting interest and investment in the health and development of the core Velocity codebase. That's hard to measure. If that's known as a criterion, people will just say the right things. How's that sound? If there are projects that aren't template engines that want to come to Apache, the door is open and they are welcome. And template engines are welcome too, right? The question is whether being here would be just about them having the foundation and infrastructure support or if there is a community aspect too. If community matters, then it matters where they fit in Apache organizationally. So rather than a blanket statement that any Velocity-related projects are welcome or not welcome, i prefer having the freedom to individually vet the merits and fit of project interested in joining the Velocity TLP. And you, as a Velocity PMC member, would be very, very welcome to join in those discussions and decisions. Sure - I think thought that the project charter should be clearer. I would love it to be. Please help! But putting anything that uses Velocity into a TLP is like using things that use log4j into the same TLP (which would re-create Jakarta... :) Yep, good thing that's not the plan! :) That's not obvious to me. Hopefully you mean that wasn't obvious to you. I've gone to some pains to explain this... :) I'm slow. geir geir geir Nathan Bubna wrote: Looks like the Velocity community is ready to head out on its own... +1 votes: Nathan Bubna Martin van den Bemt James Mitchell Henri Yandell Jorg Schaible Henning P. Schmiedehausen Will Glass-Husain Torsten Curdt Rony G. Flatscher Jesse Kuhnert Dion Gillard Daniel Rall Matthijs Lambooy Niall Pemberton Claude Brisson Malcolm Edgar Christoph Reck +0 votes: -none- -1 votes: -none- I'm not sure who's on the PMC or not, but i'm fairly sure most of those votes are binding. :) thanks, everyone! On 9/15/06, Nathan Bubna [EMAIL PROTECTED] wrote: The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So
Re: [RESULT] Move Velocity to TLP
Nathan Bubna wrote: On 9/22/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This vote closed sooner than expected. I was traveling and there was no stated deadline. Aw, c'mon. It's been in discussion on velocity-dev for over a month, and i gave the vote a full week! Not complaining, just noting why :) Still, further votes and discussion are fine with me... :) I'm +1 and -1. I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not necessary, but not unreasonable. I'm -1 because I'm worried that this is a new kind of umbrella that's planned. Making it a catchall for things that are and use Velocity is going the wrong direction. Nothing new about it. Velocity became just such an umbrella under your leading, or am i mistaken about your part in forming DVSL and VelocityTools? :) Tools was created because we wanted to offer support for struts users, and struts didn't want it. We didn't create a replacement for struts. And yeah, it grew in scope. DVSL was similar. Maybe it could have gone into commons, but again, it was home grown. And Billy did it too! isn't really a good reason to do it :) And the idea is not that all Velocity using projects are welcome, but that we are free to invite projects that are explicitly built upon or for Velocity. There are big differences between being free to invite projects and being a catchall and between being a project that uses or supports Velocity and one that is explicitly built for or upon Velocity. How do you draw the line? If there are projects that aren't template engines that want to come to Apache, the door is open and they are welcome. And template engines are welcome too, right? The question is whether being here would be just about them having the foundation and infrastructure support or if there is a community aspect too. If community matters, then it matters where they fit in Apache organizationally. So rather than a blanket statement that any Velocity-related projects are welcome or not welcome, i prefer having the freedom to individually vet the merits and fit of project interested in joining the Velocity TLP. And you, as a Velocity PMC member, would be very, very welcome to join in those discussions and decisions. Sure - I think thought that the project charter should be clearer. But putting anything that uses Velocity into a TLP is like using things that use log4j into the same TLP (which would re-create Jakarta... :) Yep, good thing that's not the plan! :) That's not obvious to me. geir geir Nathan Bubna wrote: Looks like the Velocity community is ready to head out on its own... +1 votes: Nathan Bubna Martin van den Bemt James Mitchell Henri Yandell Jorg Schaible Henning P. Schmiedehausen Will Glass-Husain Torsten Curdt Rony G. Flatscher Jesse Kuhnert Dion Gillard Daniel Rall Matthijs Lambooy Niall Pemberton Claude Brisson Malcolm Edgar Christoph Reck +0 votes: -none- -1 votes: -none- I'm not sure who's on the PMC or not, but i'm fairly sure most of those votes are binding. :) thanks, everyone! On 9/15/06, Nathan Bubna [EMAIL PROTECTED] wrote: The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So... The proposal is available for your perusal at: http://wiki.apache.org/jakarta/TLPVelocity For the interested, most of the discussion took place on the following thread: http://marc.theaimsgroup.com/?t=11553094014r=1w=2 And the vote happens here: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks! - 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: [RESULT] Move Velocity to TLP
Adding velocity-dev Henning Schmiedehausen wrote: Hi, I'm completely with Nathan here. A Velocity TLP will not be another Jakarta (though I do fail to see why everyone seems to believe that Jakata is always considered a bad example). Right - the only thing that was bad about Jakarta is that we grew too fast for scalable Apache governance, and that people identified more with Jakarta than with the ASF. On the opposite. The Velocity TLP is intended to help reducing the number of projects that Jakarta has. Which is a push that was started by Henri last year. The fact that Velocity already has a number of projects (VelocityTools, which doesn't make any sense without Velocity and same goes for DVSL; two projects that are heavily entwined with Velocity) will not go away whether it is located under Jakarta or its own TLP. I understand the whole history. I never understood the pressing need to push things out of Jakarta - projects were leaving on their own - but it doesn't really matter. I know that we will be reluctant in accepting new projects into Velocity and I hope that you will be one of the watchguards of that policy on the new Velocity PMC. But personally, I consider Clustering a good thing. I'd like a clearer charter. Having a small group of related projects available through a single point of access (like e.g. the Lucene related stuff) is a good thing. Just pushing everything top-level IMHO is not. Especially if projects are too small to go TLP. And putting e.g. VelocityTools under Jakarta would IMHO not be correct because it would be somehow lost there. A project like that would always look towards Velocity even if it is located somewhere else. For upcoming stuff: there currently is talk with Click (click.sf.net), and the relation of Click to Velocity is similar (IMHO) the the relation of Velocity to VelocityTools. They will have to go through incubation (surely) if they decide to join, but the communities of Velocity and Click seem to be an even match. So, in a nutshell: Don't worry. Velocity will not become another Jakarta. It might become another Lucene or MyFaces with a small number of clearly defined, Velocity related projects, though. Which is a good thing IMHO. I'm worried or I wouldn't be saying anything. geir Best regards Henning On Fri, 2006-09-22 at 21:18 -0700, Nathan Bubna wrote: On 9/22/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This vote closed sooner than expected. I was traveling and there was no stated deadline. Aw, c'mon. It's been in discussion on velocity-dev for over a month, and i gave the vote a full week! Still, further votes and discussion are fine with me... :) I'm +1 and -1. I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not necessary, but not unreasonable. I'm -1 because I'm worried that this is a new kind of umbrella that's planned. Making it a catchall for things that are and use Velocity is going the wrong direction. Nothing new about it. Velocity became just such an umbrella under your leading, or am i mistaken about your part in forming DVSL and VelocityTools? :) And the idea is not that all Velocity using projects are welcome, but that we are free to invite projects that are explicitly built upon or for Velocity. There are big differences between being free to invite projects and being a catchall and between being a project that uses or supports Velocity and one that is explicitly built for or upon Velocity. If there are projects that aren't template engines that want to come to Apache, the door is open and they are welcome. And template engines are welcome too, right? The question is whether being here would be just about them having the foundation and infrastructure support or if there is a community aspect too. If community matters, then it matters where they fit in Apache organizationally. So rather than a blanket statement that any Velocity-related projects are welcome or not welcome, i prefer having the freedom to individually vet the merits and fit of project interested in joining the Velocity TLP. And you, as a Velocity PMC member, would be very, very welcome to join in those discussions and decisions. But putting anything that uses Velocity into a TLP is like using things that use log4j into the same TLP (which would re-create Jakarta... :) Yep, good thing that's not the plan! :) geir Nathan Bubna wrote: Looks like the Velocity community is ready to head out on its own... +1 votes: Nathan Bubna Martin van den Bemt James Mitchell Henri Yandell Jorg Schaible Henning P. Schmiedehausen Will Glass-Husain Torsten Curdt Rony G. Flatscher Jesse Kuhnert Dion Gillard Daniel Rall Matthijs Lambooy Niall Pemberton Claude Brisson Malcolm Edgar Christoph Reck +0 votes: -none- -1 votes: -none- I'm not sure who's on the PMC or not, but i'm fairly sure most of those votes
Re: [RESULT] Move Velocity to TLP
This vote closed sooner than expected. I was traveling and there was no stated deadline. I'm +1 and -1. I'm +1 as I do think that Velocity as a TLP is not unreasonable. Not necessary, but not unreasonable. I'm -1 because I'm worried that this is a new kind of umbrella that's planned. Making it a catchall for things that are and use Velocity is going the wrong direction. If there are projects that aren't template engines that want to come to Apache, the door is open and they are welcome. But putting anything that uses Velocity into a TLP is like using things that use log4j into the same TLP (which would re-create Jakarta... :) geir Nathan Bubna wrote: Looks like the Velocity community is ready to head out on its own... +1 votes: Nathan Bubna Martin van den Bemt James Mitchell Henri Yandell Jorg Schaible Henning P. Schmiedehausen Will Glass-Husain Torsten Curdt Rony G. Flatscher Jesse Kuhnert Dion Gillard Daniel Rall Matthijs Lambooy Niall Pemberton Claude Brisson Malcolm Edgar Christoph Reck +0 votes: -none- -1 votes: -none- I'm not sure who's on the PMC or not, but i'm fairly sure most of those votes are binding. :) thanks, everyone! On 9/15/06, Nathan Bubna [EMAIL PROTECTED] wrote: The Velocity project has for some time now been making plans for a proposal to the board that the Velocity projects leave the Jakarta umbrella and become their own top level project. Martin has asked us to hold a vote on the proposal here before he passes it along to the board. So... The proposal is available for your perusal at: http://wiki.apache.org/jakarta/TLPVelocity For the interested, most of the discussion took place on the following thread: http://marc.theaimsgroup.com/?t=11553094014r=1w=2 And the vote happens here: [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Thanks! - 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] Remove SVN restrictions
Would that group auth then include everyone in the jakarta group auth? Yoav Shapira wrote: Hi, +1, with the hope that should a group state their intention to become a TLP, the process for granting them a separate auth group is quick and easy. Yoav On 3/27/06, Henri Yandell [EMAIL PROTECTED] wrote: Vote to remove the SVN barriers within Jakarta such that all jakarta-* groups are merged into the one jakarta group with the exception of jakarta-hivemind, jakarta-slide, jakarta-cactus and jakarta-jmeter under the assumption that they are moving to having their own PMCs. Tapestry is already within its own auth group. [ ] +1 [ ] -1 If your -1 is only for a particular subproject (ie: you don't care what the rest of Jakarta does, feel free to say so). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - 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: [ANNOUNCEMENT] ApacheCon EU 2006
I thought the Stanly Cup would be over by then what do you need the TVs for again? Some game w/o scoring or contact? ;) Noel J. Bergman wrote: Henning Schmiedehausen wrote: You are surely aware of the fact that this is right on top of the round of 16 and quarter-final games of The World Cup, aren't you? IMHO you probably should plan to get T.V. sets in the common areas LOL Way ahead of you. The conference producer made similar comments, as did I. But not everyone shares out passion for The Beautiful Game. --- 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: [draft] SD Magazine: request for change
On Mar 20, 2005, at 7:20 PM, Bill Barker wrote: - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: general@jakarta.apache.org Sent: Sunday, March 20, 2005 3:01 PM Subject: Re: [draft] SD Magazine: request for change Henri Yandell wrote: It may be that leading contributor is, while not an 'Apache Way' to discuss something, a completely true piece of investigative journalism. There are definitely parts of Commons where a little bit of investigation could point out that Yes, on DBUtils 1.0, David Graham was the lead developer (Sorry David :) ). That may be true, but certainly we do have the right and responsibility to ensure that our desires, as far as how we run and represent ourselves, is accurate as well. It has always been a major foundation of the ASF that projects are built and developed by communities, not individuals. Terms such as lead or main do cause harm to the community and have always been actively avoided. And, yet, all of the complaints about the article have been from people that aren't involved with Tomcat development ;-). I don't think that's very fair. The ASF spends considerable time protecting it's IP, including trademarks, for all projects. Just imagine if you read about Sun Tomcat or IBM Tomcat or you read that Microsoft controls 45% of Tomcat ;) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Apache Tomcat as a TLP ?
On Mar 21, 2005, at 3:51 PM, Noel J. Bergman wrote: Please, lets calm the things down. Henri will write an email to SD magazine, and the earth will still spin tomorrow. Well, actually, if it would pause briefly on Wednesday, that'd be OK. I have to fly east, and would rather not chase the horizon for 3000 miles. Yeah, but that would result in some serious damage to the real-estate with all the buildings disintegrating and such. Maybe the cheaper alternative is to get an upgrade to business class? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [draft-2] SD Magazine: request for change
I think this is great. More inline... On Mar 20, 2005, at 1:19 PM, Henri Yandell wrote: Added thanks for the award. Removed the text about companies not being contributors as it is nitpicking. Added note about Apache Tomcat, though I left it open to their discretion to avoid detracting from the main issue, that of the concept of a leading contributor. Hen === To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Tomcat 5.0 error in JOLT announcement Hi Kate, I'd like to thank SD/Jolt on behalf of the Jakarta community for the JOLT Productivity Winner award for Tomcat 5.0. Media recognition of the work the Tomcat community puts in is always very welcome. I'm also writing to let you know about a serious error on your JOLT product excellence awards press release because I am concerned it might be reproduced in your forthcoming June 2005 issue: http://www.sdmagazine.com/pressroom/jolt_winners_2005.pdf The release incorrectly attributes Apache's Tomcat 5.0 product to The Apache Jakarta Project and leading Tomcat contributor JBoss. There is one big problem with this attribution for us, Apache does not have a concept of leading contributors. It is completely out of sync with the very philosophies that lie at the heart of the Apache Software Foundation (ASF), as there are 70 committers to the Tomcat codebase, many of whom are employed by other companies or contribute individually. We would like to request that this be changed to: Tomcat 5.0 (The Apache Software Foundation) in both the press release (pdf url above) and the forthcoming June 2005 issue. Officially the name of the product is Apache Tomcat 5.0 and not just Tomcat 5.0, but I will leave it to your discretion as to whether you'd like to prefix Tomcat with Apache or not, as the subsequent mention of the ASF is fine. I'd actually gently push as we want this to be named Apache Tomcat 5.0. Officially, the name of the project is Apache Tomcat 5.0, and not just Tomcat 5.0, and we'd appreciate the change if that was possible. :) Well done! geir Many thanks, Henri Yandell V.P., Apache Jakarta Aw, spell this out. You want this to be as impressive as it can be for this : Henri Yandell Vice President, Apache Jakarta Project The Apache Software Foundation :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Agila : BPM engine
Yes - this is currently at the Apache Incubator as it goes through IP checking and such - I added agila to the incubator site last night, and will be creating the mail lists later this weekend. Until then, lets bring discussion over to the [EMAIL PROTECTED] mail list. geir On Sep 29, 2004, at 3:41 PM, Andreas Kuckartz wrote: Sounds interesting. Is a more detailed description availiable somewhere ? Andreas - Original Message - From: Geir Magnusson Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, September 29, 2004 8:27 PM Subject: Apache Agila : BPM engine All, The Jakarta PMC has voted to accept in Jakarta the contribution of a BPM engine from Gluecode, my employer, and I am starting the basic work of getting it into [and out of] incubation. Currently called Apache Agila, it is a small, lightweight BPM engine that we have developed as the core of our BPM product. BPM is an important part of the Java server-side stack, and we feel that this contribution will be a great 'seed' for a full-fledged BPM project at Apache. At the ASF, you can find a fairly rich set of parts for an enterprise application stack, such as Geronimo, Tomcat, Derby, Jetspeed, Pluto et al, and now there's the addition of BPM. The engine has no dependencies upon platform (like J2EE), and I'm guessing that it's easy to embed this engine into the popular framworks and platforms, such as hivemind, spring, struts, pico, etc. Agila will arrive with simple HTML GUI via a servlet, and JDBC-based persistence, but these are services that can be replaced with other implementations. For example, the Gluecode product does a JSR-168 portals and J2EE-based implementation of the services. Anyway, this is a notice of what's happening, and an invitation to all to come and participate in the project. I've CC-ed [EMAIL PROTECTED], but lets keep the conversation about it here in the incubator for now. I'll be setting up the mail-lists first, and will note when that happens so we can switch . Thanks geir -- Geir Magnusson Jr +1-203-665-6437 [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] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I use Hibernate in an Apache project without compromising the Apache License?
On Sep 29, 2004, at 3:50 AM, Henning Schmiedehausen wrote: On Tue, 2004-09-28 at 11:11, Brett Porter wrote: is not ASF License compliant? If yes, than I would really hate to have to point you at http://cvs.apache.org/viewcvs.cgi/maven-plugins/hibernate/src/main/ org/apache/maven/hibernate/beans/SchemaExportBean.java?annotate=1.7 This would compromise all Maven releases that include the maven-hibernate-plugin. We distribute Binary and Source from apache.org sites... Thanks for bringing this up. I've been meaning to respond to this thread with that in mind. I think we've checked this in the past and because the ASF is not distributing the hibernate code, there wasn't a problem (as you say, hibernate is downloaded from ibiblio when the user chooses to use the hibernate plugin). So what would the answer of the first question of Oliver (can I use Hibernate in an ASF project) now be? still no If I got it right; Oliver wants to implement a Slide Store that uses Hibernate as back-end. According to your answer, he could do this as part of the official Slide distribution, as long as it does not contain the hibernate.jar itself (which could be downloaded as part of the build process (maven or ant)). I agree, that we need a clarification (best would be a legal council backed clarification). This isn't a clear-cut legal issue, like speeding or stealing. The problem is that the ASF position is that the LGPL is unclear, and the FSF won't clarify in an official way. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I use Hibernate in an Apache project without compromising the Apache License?
On Sep 29, 2004, at 4:56 AM, Vadim Gritsenko wrote: Henning Schmiedehausen wrote: On Tue, 2004-09-28 at 11:11, Brett Porter wrote: is not ASF License compliant? If yes, than I would really hate to have to point you at http://cvs.apache.org/viewcvs.cgi/maven-plugins/hibernate/src/main/ org/apache/maven/hibernate/beans/SchemaExportBean.java?annotate=1.7 This would compromise all Maven releases that include the maven-hibernate-plugin. We distribute Binary and Source from apache.org sites... Thanks for bringing this up. I've been meaning to respond to this thread with that in mind. I think we've checked this in the past and because the ASF is not distributing the hibernate code, there wasn't a problem (as you say, hibernate is downloaded from ibiblio when the user chooses to use the hibernate plugin). So what would the answer of the first question of Oliver (can I use Hibernate in an ASF project) now be? If I got it right; Oliver wants to implement a Slide Store that uses Hibernate as back-end. According to your answer, he could do this as part of the official Slide distribution, as long as it does not contain the hibernate.jar itself (which could be downloaded as part of the build process (maven or ant)). The problem, AFAIU, is that this Maven's code now has to become LGPL licensed itself, due to LGPL license requirements. And ASF repositories can't contain LGPL code. So the answer is to pull (quickly) this code from Maven, and not to introduce to Slide. No - LGPL isn't viral unless you make derivative works of the LGPL-ed code itself. Just using an LGPL-ed codebase as a library does not trigger the virality. The problem is that for java, there are questions about the clarity of the provisions in the license that prevent the virality from taking effect, which is why the ASF doesn't allow LGPLed java usage. This is a position that I'm trying to find a compromise for. geir I agree, that we need a clarification (best would be a legal council backed clarification). Having to move every bit of maven code that references LGPL off-ASF would hit quite a few plugins. :-( Somebody could setup mavendev.org (see cocoondev.org) to host (L)GPL pieces. PS Copying PMC because action is required Vadim -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I use Hibernate in an Apache project without compromising the Apache License?
On Sep 27, 2004, at 11:37 AM, Tim O'Brien wrote: For Oliver's sake, could we submit the question to ASF counsel and see if there is any way to allow us to use Hibernate in even the most round about way. Our counsel would have no opinion different than what you've heard. We (the ASF) have tried to get a clear statement from the FSF, and so far, none have been forthcoming. Even though I'm fairly certain of the answer (no). It would be nice to get a firm answer - yes or no - from an officer or the board. What is the best way to bring this to the boards' attention. Email to Greg, copying Robyn Wagner? board_hat no /board_hat This is an issue important to me as well - I'd like to see this go away, so we can use software w/ the LGPL. But until the problem is resolved, right now the only way is to use via a dynamic dispatch mechanism. I've been thinking about this for a while, and have some funny solutions requiring a bit of classloader magic. Happy to start something in the sandbox :) geir I just don't feel comfortable telling someone this is impossible without getting a firmer legal opinion. I'm certain that IANAL applies to most of us. Tim O'Brien -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Monday, September 27, 2004 12:03 PM To: Jakarta General List Subject: RE: Can I use Hibernate in an Apache project without compromising the Apache License? Mahler Thomas wrote: You might consider Using Apache OJB (http://db.apache.org/ojb). It can do everything that hibernate can do - and more. We don't hear much (enough?) about OJB. Has anyone written up an OJB for Hibernate Users type document? --- 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] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I use Hibernate in an Apache project without compromising the Apache License?
On Sep 27, 2004, at 4:41 PM, Henri Yandell wrote: On Mon, 27 Sep 2004, Geir Magnusson Jr. wrote: This is an issue important to me as well - I'd like to see this go away, so we can use software w/ the LGPL. But until the problem is resolved, right now the only way is to use via a dynamic dispatch mechanism. I've been thinking about this for a while, and have some funny solutions requiring a bit of classloader magic. Happy to start something in the sandbox :) Is the problem with LGPL at ASF only a Java issue? Can httpd depend on LGPL'd code? Yes, because the LGPL was 'fixed' back in 92 to solve the problem what what C and C++ compilers do, namely create combined work at compile time. For example, an inline function in a C++ header can be included completely by the compiler in an object file. I think that' why they have the weird wording in the LGPL that allows 20 lines or less, or something like that. If so, then funny solutions sound useful. If it's a problem for all ASF languages, then it's pointless to do anything. It applies to Java, and I'm sure other languages as well. IMO the problem is that they patched the LGPL for a specific technology, and the world has moved on. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I use Hibernate in an Apache project without compromising the Apache License?
On Sep 27, 2004, at 4:20 PM, Oliver Zeigermann wrote: Geir Magnusson Jr wrote: On Sep 27, 2004, at 4:41 PM, Henri Yandell wrote: On Mon, 27 Sep 2004, Geir Magnusson Jr. wrote: This is an issue important to me as well - I'd like to see this go away, so we can use software w/ the LGPL. But until the problem is resolved, right now the only way is to use via a dynamic dispatch mechanism. I've been thinking about this for a while, and have some funny solutions requiring a bit of classloader magic. Happy to start something in the sandbox :) Is the problem with LGPL at ASF only a Java issue? Can httpd depend on LGPL'd code? Yes, because the LGPL was 'fixed' back in 92 to solve the problem what what C and C++ compilers do, namely create combined work at compile time. For example, an inline function in a C++ header can be included completely by the compiler in an object file. I think that' why they have the weird wording in the LGPL that allows 20 lines or less, or something like that. If so, then funny solutions sound useful. If it's a problem for all ASF languages, then it's pointless to do anything. It applies to Java, and I'm sure other languages as well. IMO the problem is that they patched the LGPL for a specific technology, and the world has moved on. I know I keep repeating myself all the time, but for the special case of Hibernate doesn't this http://www.hibernate.org/196.html clarify the issue? Of course if you people say I must not use it in a Apache Project it is ok with me, but I still do not get the point why. But then, maybe it isn't that important that I - personally - get it ;) I don't think it fixes it because it's just some web page - it's not part of the license. I've asked Gavin directly to modify the license to reflect this, hoping that it would resolve the problem. He refused :) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: Author tags
On Sep 13, 2004, at 12:38 PM, Craig McClanahan wrote: Recently, a new twist on @author tags came up, from a direction I never would have expected. It seems that the JDK 1.5 compiler whines when you have non-ISO-8859-1 characters in Javadoc comments in your source files. Someone was kind enough to run a compile of a bunch of open source projects with 1.5, to help identify projects that have such sources. It turns out that commons-beanutils has a few such occurrences -- because of non-ASCII characters in the authors's names in the @author tags. Guess we need to tell such people to change their names if they want to be an @author :-). Or tell Sun to fix their compiler... geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
(Jakarta|Geronimo|Groovy|*)One
Seems like the Thirsty Bear is going to be the place to count on finding people, and seems like wed *and* thursday nights are going to be populated by people from the above... Hope to meet as many as possible. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: JavaOne Blogger Meetup Next Monday - Confluence]
On Jun 25, 2004, at 4:48 PM, Kevin Burton wrote: We talked about a month ago of a JakartaOne gathering during JavaOne. I figured it just makes sense for us to just meet at the bloggers meeting. Or does it make sense to have a dedicated Jakarta gathering? Thoughts? I'd like to propose that we do it wednesday at the Thirsty Bear. We'll probably have two other groups there, a GroovyOne, and a GeronimoOne, and if we can get momentum of OSS groups, we can get more to come. geir Original Message Subject: [Dev] JavaOne Blogger Meetup Next Monday - Confluence Date: Thu, 24 Jun 2004 01:00:03 -0700 From: Kevin Burton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date Monday 28th June 2004 Time From 6:30pm Location The Thirsty Bearimage.tiff (at the back) Other locations ...to be staggered to later in the evening Who will be there? Hopefully, everyoneimage.tiff http://confluence.atlassian.com/display/JAVABLOGS/2004/06/22/ JavaOne+Blogger+Meetup+Next+Monday -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster mime-attachment___ Dev mailing list [EMAIL PROTECTED] http://mail.sofari.com/mailman/listinfo/dev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi:
I'd ask this question on the struts user site. find info here : http://struts.apache.org/ On Jun 17, 2004, at 7:40 AM, gitanjali wrote: Hi all, i m trying to do connectivity in struts but failing .can any body tell me what exactely i have to do. thnx in advance. Anjali Yahoo! India Matrimony: Find your partner online. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nag email for dom4j project
On Jun 17, 2004, at 9:05 AM, Maarten Coene wrote: Hi, is it possible to send an email to the dom4j-dev emaillist everytime the build of dom4j fails? The address is [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] You might want to send this to someone in the Gump project. http://gump.apache.org/ thanks, Maarten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Watchdog] Dead?
On Jun 7, 2004, at 5:05 AM, Danny Angus wrote: Geir wrote: Well, I'm a little leery about sending watchdog traffic (even if none) to general@ - all it takes is one guy getting interested :) (My silence was due to temporary no-email-at-home, not indifference!) I'd prefer to propose the following: 1/ that a PMC vote is taken *HERE* to decide if the community is happy to see Watchdog downgraded to inactive That's fine, although I see no need to 'downgrade'. I think that the PMC is aware, and Yoav and yourself have karma now. As for the rest, do what you think is best. You've got Karma. If someone doesn't like, they'll squawk. :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Watchdog] Dead?
On May 26, 2004, at 9:33 AM, Shapira, Yoav wrote: Hi, I just tried to subscribe to the watchdog mailing list in order to notify the developers of a bug I submitted against Watchdog. But I got a no such mailbox: [EMAIL PROTECTED] error response from the mail server. What's the status of Watchdog? I just added Yoav and Danny to the committer list for watchdog. You guys decide on what you want to do with the mail list. I think just getting the -dev and -user going again for watchdog would be a clean, unconfusing way to do it, but it's for you decide. I don't think that working, used-by-users code is 'dead'. There may not be an active community of developers, but if the code is done, it's done. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Watchdog] Dead?
On Jun 4, 2004, at 1:14 PM, Noel J. Bergman wrote: Yoav Shapira wrote: For interest's sake, let me explain what's been happening with Watchdog, as I think it's a useful example for other graveyard or end-of-life scenarios. We use Watchdog as part of the tomcat release process. A tiny change to the Watchdog build.xml would fix [a problem], and I've submitted a Bugzilla enhancement request with the patch. But there's no one to act on my request The idea of partitioning permissions within a TLP, as is extensively the case within Jakarta, is broken. A TLP is supposed to be a single cohesive community. Ideally, the PMC consists of all active committers. Were there a TLP for Tomcat and related tools, I suspect that Watchdog would be in that TLP, even if Watchdog is also useable by other containers, and you would have the necessary access rights. Even in the current circumstance, it seems to be that the Tomcat community might want to take responsibility for Watchdog. Well, I disagree that the idea is broken, but we can leave that for another thread. Having Tomcat community take care of watchdog would be great, and it doesn't imply any major work like moving the code or site. Just paying attention to the lists and putting a notice on the Watchdog site to the effect of dormancy would be an excellent start. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Watchdog] Dead?
On Jun 4, 2004, at 1:31 PM, Shapira, Yoav wrote: Hi, OK, then let me propose this: - We give Danny Angus and myself karma for Watchdog. There are no active committers to nominate us. +1 - Either one of us will place a notice of dormancy (text TBD) on the front page for Watchdog +1 - I will fix the build script so that Tomcat builds can be automated in this regards I don't know what this means, but if you're happy, I'm happy. We still need to take care of the mailing lists. I see two options: - We revive the watchdog-dev/watchdog-user mailing lists and redirect them somewhere like [EMAIL PROTECTED], or - We just leave them dead, take off the subscription links on the Watchdog site, and indicate in our notice of dormancy that questions about watchdog should be submitted to [EMAIL PROTECTED] Why not just monitor them? geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Watchdog] Dead?
On Jun 4, 2004, at 1:45 PM, Shapira, Yoav wrote: Hi, We still need to take care of the mailing lists. I see two options: - We revive the watchdog-dev/watchdog-user mailing lists and redirect them somewhere like [EMAIL PROTECTED], or - We just leave them dead, take off the subscription links on the Watchdog site, and indicate in our notice of dormancy that questions about watchdog should be submitted to [EMAIL PROTECTED] Why not just monitor them? There's nothing to monitor: the lists are dead. Emails to watchdog-dev-subscribe/unsubscribe come back with an address not found type error. And yet those are the addresses linked on the watchdog site. So we actually have broken and misleading information there ;) (!) So why don't we just fix them? -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Watchdog] Dead?
On Jun 4, 2004, at 1:54 PM, Shapira, Yoav wrote: Hi, There's nothing to monitor: the lists are dead. Emails to watchdog-dev-subscribe/unsubscribe come back with an address not found type error. And yet those are the addresses linked on the watchdog site. So we actually have broken and misleading information there ;) (!) So why don't we just fix them? The lists were not removed accidentally, so I assume the developers at that time had some rationale. Beyond that, I'm assuming the activity level on these lists would be so low that redirecting them to [EMAIL PROTECTED] is fine. If my assumption is proven wrong we can recreate/revive the lists and update the watchdog web site accordingly. Well, I'm a little leery about sending watchdog traffic (even if none) to general@ - all it takes is one guy getting interested :) geir Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any interest in a Jakarta JavaOne BOF?
We've been chatting among ourselves about another JakartaOne, as we called the first one a few years ago. it was a great get-together, in a bar near Moscone. Lets extend the invitation too to the other Java-using groups. I'll post a message to community@ and see what interest we can get. geir On May 21, 2004, at 5:00 PM, Kevin Burton wrote: It's about a 1.5 months away but I figured I would try to get a pulse on how much interest there is in holding a JavaOne BOF. We've contacted SUN directly and they seem interested... though to be honest I was thinking it would be better to just have us meet at a bar or maybe at our offices since we're 1/2 a block away from the Metreon. So I'm thinking beer, pizza, wifi... music... could be fun. We might not be able to host it at our offices but there are a few places around the hood we could rent out. So how many people would be interested...?! PS... We're hiring REALLY smart people experienced in Jakarta tools... email me private for more info. -- Please reply using PGP. http://peerfear.org/pubkey.asc NewsMonster - http://www.newsmonster.org/ Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965 AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NOTICE] HttpClient is requesting to move from commons to Jakarta sub-project
All, The HttpClient project has voted to ask to become a Jakarta sub-project. The PMC is voting on expanding Jakarta, and I personally apologize to the community for accidentally holding the vote on the private PMC list. In order to keep confusion to to a minimum, we'll keep it there and do better next time. If anyone has any comments, speak now or forever hold it... :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] HttpClient is requesting to move from commons to Jakarta sub-project
On Apr 14, 2004, at 4:09 PM, Adrian Sutton wrote: Geir et al, Sorry that was my fault. It was my understanding that the PMC had to vote on it and thus logical to forward it to [EMAIL PROTECTED] I had however forgotten to take into account the fact that pmc@ is a private list. LOL. You did the right thing. HttpClient voted as a community to ask Jakarta to be a sub-project. We the PMC had to initiate a formal vote, and I made the mistake of doing it on the pmc list... geir Regards, Adrian Sutton. On 15/04/2004, at 2:29 AM, Geir Magnusson Jr wrote: All, The HttpClient project has voted to ask to become a Jakarta sub-project. The PMC is voting on expanding Jakarta, and I personally apologize to the community for accidentally holding the vote on the private PMC list. In order to keep confusion to to a minimum, we'll keep it there and do better next time. If anyone has any comments, speak now or forever hold it... :) geir -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
On Mar 22, 2004, at 6:02 AM, Danny Angus wrote: Having named leads of any sort is the antithesis of what I would like to see within the ASF. Fair enough, but there's no reason I can see why a JCP lead shouldn't be an OSS chair, I guess the JCP needs spec leads like the ASF needs chairpeople, to be a single point of refrence from above and a single focus for oversight from below. THe difference is that the spec lead generally owns the resulting spec and licensing rights. geir I'm sure that a great many of us work in teams with a team leader who isn't an autocratic megalomaniac, but largely the point of contact between above and below d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. *** *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
On Mar 19, 2004, at 12:17 PM, Henri Yandell wrote: This is a little linked to the Apache-open source question raised a while back, though it actually comes from trying to explain to someone what the pro's and reasons for groovy as a jsr might be. How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP process? If there's anything the ASF are not happy with in the JCP we can adjust it, but generally we would manage our own projects in the same way that ASF involvement in the JCP.org says we should manage standards. Are you kidding? We'd have to go to meetings and discuss process documents. I do that 4 times a year as is as JCP rep, and that's more than enough! What I'm largely interested in are the reasons why not, as these would be perfect reasons why something like groovy, or ant or httpclient, should not become jsr's. Groovy is going through the JSR process so that the language will be formalized into a spec and protected for compatibility. This will give the Java ecosystem another language the runs on the JVM for which claimed implementations are guaranteed to be compatible. So... why not run [EMAIL PROTECTED] under the JCP process? Because there is no real need to assert that every project at the ASF in Java is some sort of standard, and further, doing a TCK is an awful lot of work. If we do have something that is a candidate to be standardized, we can go to the JCP and do it there. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
On Mar 19, 2004, at 1:44 PM, Noel J. Bergman wrote: How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP process? In what way? Can you be specific? As I understand the JCP, what you are asking makes little sense. We don't have spec leads, nor do we want them. We don't have ownership of a project/specification. Everything here is communal and consensual. That is not true of the JCP. Actually, I would prefer to see the JCP continue to evolve to become more like the ASF. What I'm largely interested in are the reasons why not, as these would be perfect reasons why something like groovy, or ant or httpclient, should not become jsr's. A JSR is a specification. It should have a TCK and an RI, but at heart it is a specification. Some people have talked about proposing the Apache Repository Specification, which I understand Maven will evolve to use, as a JSR. If that happened, I'd prefer to see us run a JCP Expert Group more in line with an ASF project, not run ASF projects like an JCP Expert Group. That would be a good example of something that would be appropos for a JSR - something that others will/might implement, and if so, you want to be sure that your software which works with one implementation of it works with others. Geir? Your thoughts? We are always working to help move the JCP towards the OSS model, but it's a slow process. In JCP 2.5 (the guidelines for the JCP), the ASF's work was key in getting TCKs and RIs to be able to be licensed under and OSS license. Before that, there was no way to do an OSS JSR. Now, w/ 2.6 that just went into effect last week, the process now formally encourages as much openness and transparency as possible in an EG (although you still can do pretty much what you want...) as well as require an early release of the spec to the community to enable as much feedback and commentary as possible. Previously, the EGs had to release a community draft late in the process, and that made them afraid to have not enough time to fix stuff, so they would tend to really delay. The Groovy EG will be run as an OSS project, btw... geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache should join the open source java discussion
On Mar 18, 2004, at 8:16 AM, Leo Simons wrote: Something big is stirring in the java world. There's talks between Sun and IBM about releasing an open source version of java. There's talks between the linux desktop movers about adopting java as the glue that binds the major desktop projects together. Key ASF individuals are joining these discussions, on weblogs and various discussion forums. But the ASF as a whole is silent. Apache is one of the biggest open source communities, and the leader of the pack when it comes to open source java. I think the Apache community should work together on an open letter to Sun, IBM, and the rest of the open source community stating our shared position on the subject. Like Havoc Pennington writes (http://ometer.com/desktop-language.html), the Community Should Decide and It's time to start the discussion. WDYT? The ASF has always been a proponent for 'open source java', and while I'm glad to see the rest of the world catching up, I believe the path we are on is fundamentally a good one, and we shouldn't deviate too far from it. Here's something I wrote a little while ago for the members list, describing what we do and will do : 1) Keep working to make TCKs available to ASF projects that implement JSRs, and when needed, infrastructure to run the TCKs. We cover the spectrum - from smaller WS stuff (including something for J2ME, IIRC), to the big mosnster, J2EE. The main activity is getting TCKs in the hands of non-members to use in ASF projects, something thats just requiring some legal paperwork. Given that we'll have a larger and larger group using TCKs, willing to fix them if given the chance, I see oppo for OSS-ing TCKs. Maybe I'm a dreamer. (Note that new the proposed JSR 241 for Groovy is going to be an OSS TCK and OSS RI). 2) Bring RIs here to the ASF. We have a good tradition of this already, Tomcat and JSP for example, and we need to continue it, either by taking on ownership of existing RIs, such as we are working on for JavaMail, or hosting RIs for EGs on which the ASF has a rep (or not). This will tend to force the open spec issue, as you can't get the free help of an OSS community if they can't read the spec and know the motivations behind APIs. 3) Do what we can to connect the various JSR-implementors in the OSS community. For example, we'd like to connect all J2EE implementors, both OSS and non-OSS (so JBoss would be invited), to talk confidentially with each other about issues they face to pass the TCK. This would expose the OSS communities w/ the commercial community in a deep, technical way, which I think will help the commercial crowd form an accurate picture of OSS. We are the only open source entity on the Executive Committee of the Java Community Process. The efforts of the ASF (w/ Jason as rep) resulted in pro-OSS changes in a de-facto international standards group. These changes included free JCP participation for individuals, academics and non-profits, the ability to actually create a TCK and RI under an OSS license, and the creation of the scholarship program for individuals, academics and non-profits to get TCKs and RIs free of charge w/ free support to certify open source projects. One very visible result of this is that the ASF and ObjectWeb are both J2EE licensees, and working to create certified open-source J2EE stacks. Since this recent brouhaha started, the intention is to get involved (me wearing the VP JCP and VP Jakarta hats makes me itch to do something :) At first I wanted to make a public statement too, but after thinking about it for a while, and since we had a nice quote from Brian in the first news cycle, I put that aside for a little while. This is a somewhat tricky issue due to the compatibility concerns and politics involved, and it's clear that we can be most effective if a) we are sure to continue to be a neutral party in what is currently visible as a Sun vs IBM public pissing match - IOW, we don't pile on Sun (nor ignore IBM) b) we completely understand the issues facing all sides (well, both sides, Sun and IBM, as I don't really care what ESR's issues are...) To that end, I've been working privately (w/ JCP hat on) with a few people, and wish to continue that way for a little while. I don't want this to appear as anything more than me just talking to people - not an official ASF action by any means - and I really wanted to keep quiet about it, but your post brought this front and center. I think the best thing that ASF community members can do for now, until the next news flareup, is in blogs, conversations etc, is point out how much the ASF does wrt 'open source java' - how this isn't a new idea and we're working hard to make it happen. And we're doing it not in the press, but where the rubber meets the road - through code and community. This isn't a meme to be planted - just a fact to disseminate. :) geir -- Geir Magnusson Jr
Re: Apache should join the open source java discussion
sheepish I wasn't subscribed to community@ until now, so if there's something there that wasn't xposted to general@, let me know... /sheepish More inline : On Mar 18, 2004, at 11:21 AM, Leo Simons wrote: Geir Magnusson Jr wrote: the intention is to get involved snip/ really wanted to keep quiet about it, but your post brought this front and center. little did I know! See what happens when stuff happens on private mailing lists? Duplication of effort :-P LOL it wasn't on a private list. There was some informal discussion, and I kept meaning to bring it up to the community in general... I'll happily shut up, since you're obviously on top of things. And thanks for letting us know you're on top of things :D I won't claim to be on top of anything yet, but certainly will keep trying... geir -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache should join the open source java discussion
On Mar 18, 2004, at 11:06 AM, Costin Manolache wrote: Serge Knystautas wrote: Leo Simons wrote: Key ASF individuals are joining these discussions, on weblogs and various discussion forums. But the ASF as a whole is silent. In lieu of forming a statement for the ASF as a whole, what about organizing/encouraging/guiding people who want to participate? Maybe specific resources that should be targetted, such as where the most active and/or productive discussions are taking place. What about starting by making sure Apache java projects _do_ work with the 2 open source JVMs that are mentioned in the article ? That would be a statement, much better than we like open source java, but our software doesn't run on it because it doesn't really matter. Perfect - this is the way that the ASF has always supported open-source java - by actually doing it... geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE RESULT] HiveMind as Jakarta sub-project
The vote has been running a week now (actually longer), the count has been unanimously supportive (there were two +0 votes, all the rest were +1), so HiveMind is now a Jakarta sub-project. Congratulations to Howard and the rest of the HiveMind community. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: entering jakarta
On Mar 3, 2004, at 7:24 AM, Paulo Simao wrote: Hi Folks I´m new in the group. I read all the docs in jakarta site, but I´m not sure about the process for donating code and starting a project. It would be very helpfull, if someone could give me a small guidance.'' If you have some contributions to make for an existing Jakarta sub-project, work with that community via the mail lists. If you have and idea about something new to start, you have two options. If appropriate to the Jakarta Commons, you might try to ignite a discussion about your ideas there. If it's larger and far enough along in development, the Apache Incubator would be a good place to discuss. geir Thank you all for the attention. Paulo Simao _ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] HiveMind as a Jakarta sub-project
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*. [ ] +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 :) -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HiveMind as a Jakarta sub-project
On Mar 3, 2004, at 9:58 AM, 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 -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: news reorganization
On Mar 3, 2004, at 4:24 PM, robert burrell donkin wrote: On 25 Feb 2004, at 13:33, Geir Magnusson Jr. wrote: On Feb 24, 2004, at 5:08 PM, robert burrell donkin wrote: i've just committed the reorganization i proposed last week. i've moved all the news documents into the news subdirectory and all now have date-related names (so no renaming should be necessary and therefore the urls will be permanent). the html versions of the old pages now redirect to the new ones. i'm considering adding some other redirects into the .htaccess file. That's great. Any support for moving the link to Martin's page up, have a separate section above news In memoriam or like? done. Thanks. Very nice. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] HiveMind as a Jakarta sub-project
On Mar 3, 2004, at 6:56 PM, [EMAIL PROTECTED] wrote: -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] [X] +1 I support this proposal [ ] -1 I don't support this proposal [ ] 0 I abstain from voting for or against this proposal Comments : Are releases going to use HTTPD release numbering or the Jakarta method ? There is a jakarta method? -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: questions license for site documents
On Feb 29, 2004, at 5:57 AM, robert burrell donkin wrote: the generated html does not contain an explicit license just a copyright. am i right in thinking that now it would be better to publish them under the apache license 2? also, am i right in thinking that all the source documentation should have license notices added? Might as well make it explicit - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Migration
On Feb 26, 2004, at 8:38 PM, Scott Eade wrote: According to http://nagoya.apache.org/wiki/apachewiki.cgi?MigrateFromThisWiki and http://wiki.apache.org/general/UseModMigration we eventually need to migrate the existing Usemod wiki content over to the new MoinMoin wiki. For jakarta I would imagine that we will want a subwiki per subproject. I would like to migrate the turbine project pages across as a subwiki called turbine under a Jakarta heading (with change diffs going to the turbine-dev mailing list). I am only volunteering to migrate the turbine project pages, but if others want to put their hands up for other subprojects then perhaps a single request to infrastructure could be used to request multiple subwikis. As I understand it there needs to be a consensus in the jakarta PMC that this is the way forward before a request can be made to infrastructure to create any subwikis. Do any PMC members object to this approach? Does this mean we can have ./jakarta ./jakarta/turbine ./jakarta/whatever Where turbine and whatever are distinct and separate, not just parts of /jakarta? geir Thanks, Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Migration
On Feb 26, 2004, at 10:31 PM, Mark R. Diggory wrote: What about non-project related wiki content like the following, where would that go in the new wiki? http://nagoya.apache.org/wiki/apachewiki.cgi?GettingInvloved http://nagoya.apache.org/wiki/apachewiki.cgi?ToolChest http://nagoya.apache.org/wiki/apachewiki.cgi?IrcChannels I'd like for us to have a general Jakarta wiki for the whole community geir -Mark Henri Yandell wrote: Sounds good to me, I think Commons can work fine as a single Wiki. Continues to allow for interesting inter-component relations. Taglibs also fits well as a single Wiki. +1 (PMC) I'm unsure if either have a wiki, but am prepared to learn the necessaries to migrate if need be. Hen On Fri, 27 Feb 2004, Scott Eade wrote: According to http://nagoya.apache.org/wiki/apachewiki.cgi?MigrateFromThisWiki and http://wiki.apache.org/general/UseModMigration we eventually need to migrate the existing Usemod wiki content over to the new MoinMoin wiki. For jakarta I would imagine that we will want a subwiki per subproject. I would like to migrate the turbine project pages across as a subwiki called turbine under a Jakarta heading (with change diffs going to the turbine-dev mailing list). I am only volunteering to migrate the turbine project pages, but if others want to put their hands up for other subprojects then perhaps a single request to infrastructure could be used to request multiple subwikis. As I understand it there needs to be a consensus in the jakarta PMC that this is the way forward before a request can be made to infrastructure to create any subwikis. Do any PMC members object to this approach? Thanks, Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au - 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] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Migration
On Feb 26, 2004, at 10:40 PM, Scott Eade wrote: Mark R. Diggory wrote: What about non-project related wiki content like the following, where would that go in the new wiki? http://nagoya.apache.org/wiki/apachewiki.cgi?GettingInvloved http://nagoya.apache.org/wiki/apachewiki.cgi?ToolChest http://nagoya.apache.org/wiki/apachewiki.cgi?IrcChannels If the PMC is agreeable the Jakarta heading (I see it is there now with a jakarta-cactus subwiki) could itself be a subwiki to provide a place for these non-project documents (with change diffs emailed to this list). The Incubator and Logging projects seem to take this approach. That answers my first question. We can't structure the wiki's such as I was thinking before. +1 Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Migration
On Feb 27, 2004, at 8:13 AM, Scott Eade wrote: Geir Magnusson Jr. wrote: Does this mean we can have ./jakarta ./jakarta/turbine ./jakarta/whatever Where turbine and whatever are distinct and separate, not just parts of /jakarta? Not quite - the wiki urls would all be at the same level. Using separate wikis thus: ./jakarta ./turbine ./jakarta-commons has a few advantages: 1. Oversight can be improved by sending change diffs to the list most appropriate to the wiki concerned. 2. Potential migration of subprojects to top level projects could simplified (especially if we use, for example, turbine rather than jakarta-turbine as the name of the turbine wiki). 3. Separate wikis means independent namespaces for WikiWords. All if these could be solved if the design of the wiki system wasn't broken. The URL should be just that, the URL, and structure of the Wiki was distinct. IOW, it would be nice for separate wiki's to be able to be assembled any way we wanted. Including links between separate wikis is easily achieved through the use of InterWiki links. Would anyone like to comment on a preferred naming convention - i.e. turbine vs jakarta-turbine (I see we now have jakarta-cactus and jakarta-tapestry). I don't know if it is difficult to change the name of a wiki from say jakarta-cactus to just cactus if say cactus were to become a top level project in the future, so perhaps just cactus might have been a more future-proof choice. If we can do 'jakarta-cactus' until it's a TLP w/o much work to convert, that would probably be better... geir Scott -- Scott Eade Backstage Technologies Pty. Ltd. http://www.backstagetech.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: news reorganization
On Feb 24, 2004, at 5:08 PM, robert burrell donkin wrote: i've just committed the reorganization i proposed last week. i've moved all the news documents into the news subdirectory and all now have date-related names (so no renaming should be necessary and therefore the urls will be permanent). the html versions of the old pages now redirect to the new ones. i'm considering adding some other redirects into the .htaccess file. That's great. Any support for moving the link to Martin's page up, have a separate section above news In memoriam or like? -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chairmen..
On Feb 23, 2004, at 5:28 PM, Danny Angus wrote: If its not too patronising of me I'd like to propose vote of thanks to Sam as outgoing chair, Sam, I know you've been more involved elsewhere lately, but from a personal point of view I've learned to respect and appreciate the low-key, mature and consensus building way in which you have steered Jakarta through a period of great change. You have worked hard to ensure that allegations of conservatism couldn't be levelled at Jakarta, and have sucessfully encouraged project after project to grow up and follow their own star. If more of us were more like you we'd've achieved so much more by now. Thanks its appreciated. Thanks Sam, for everything that you've done. And thanks for sticking around :) On a related note, welcome Geir, I'm sure you can count on us to continue to be a bunch of cranky opinionated blowhards who couldn't reach a real decision if our lives depended upon it. :-) I'm counting on it! geir d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HiveMind] There's that grant!
On Feb 24, 2004, at 11:56 AM, Howard M. Lewis Ship wrote: I guess this is as much of a notification as we get? In any case, the grant appears to have been recorded. Fabulous. Since I believe that your intention is to make it a Jakarta sub-project, the Jakarta PMC should vote to accept or reject it's addition to Jakarta. If you agree, then we should probably do this first, and assuming success, approach Incubator with the project and the wish of Jakarta to host the project once it passes all incubator requirements. Comments? geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CLAs : Deadline is March 1, 2004 to avoid suspension of commit privs
Jakarta Committers, The March 1 CLA deadline for CLAs is approaching quickly. As you are aware, all committers working on Apache Software Foundation projects are required to have a CLA filed with the ASF. This document clearly defines the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. Every committer is responsible for ensuring a CLA is on file with the ASF by March 1, 2004. Any committer that does not have a CLA on file will have their committer privs suspended. To check to see if one is on file for you, please look here : http://www.apache.org/~jim/committers.html If your name is *not* in italics, there is no CLA on file. f you are not listed as having a CLA on file, read about it and get one : http://www.apache.org/licenses/#clas and follow the instructions. It's really easy. Please direct all questions and problems to [EMAIL PROTECTED] or the public list if you don't mind public discussion of your situation. We will do what we can to help resolve any issues that arise. Silence on this issue isn't an option. The ASF is working to tie up any IP-related loose-ends, and this is an important one - they will suspend commit privs. Thanks geir, writing on behalf of the Jakarta PMC -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache License 2.0 came into effect
On Jan 28, 2004, at 9:41 AM, [EMAIL PROTECTED] wrote: If all licenses must be updated by March 1st 2004, you'd better get us some using instructions really quickly, e.g. what goes in Copyright [] [name of copyright owner] for all our existing code? Will someone need to look up the original author and all updaters in CVS? Why? The Apache Software Foundation is the copyright owner for any and all code in ASF CVSs and projects. geir -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Tetsuya Kitahata [EMAIL PROTECTED] wrote on 24/01/2004 12:01:01 PM: Hello, Jakarta-Folks, Just a note (but very important) ++ brief summary ++ The Board has approved the new Apache License 2.0. For a copy of that license, please see http://www.apache.org/licenses/. The Board has also mandated that all ASF software must be switched to the new license by March 1st, 2004. Please watch this space for further instructions on how to use the new license. - ++ description ++ The 2.0 version of the Apache License was approved by the ASF (The Board has approved the new Apache License 2.0) in 2004. The goals of this license revision have been to reduce the number of frequently asked questions, to allow the license to be reusable without modification by any project (including non-ASF projects), to allow the license to be included by reference instead of listed in every file, to clarify the license on submission of contributions, to require a patent license on contributions that necessarily infringe the contributor's own patents, and to move comments regarding Apache and other inherited attribution notices to a location outside the license terms (the NOTICE file [1]). The result is a license that is compatible with other open source licenses, such as the GPL, and yet still remains true to the original goals of the Apache Group and supportive of collaborative development across both nonprofit and commercial organizations. All packages produced by the ASF will be implicitly licensed under the Apache License, version 2.0, unless otherwise explicitly stated. For more information, see Apache Licenses Page [2] [1] - http://www.apache.org/licenses/example-NOTICE.txt [2] - http://www.apache.org/licenses/ - You can also read this above from here: http://jakarta.apache.org/site/elsewhere.html#20040121.1 Sincerely, - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ - 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] -- Geir Magnusson Jr 203-247-1713(m) [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)
On Jan 14, 2004, at 3:30 PM, Henri Yandell wrote: On Wed, 14 Jan 2004, Noel J. Bergman wrote: 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 If you are nominated and not elected people would know. Otherwise, there is privacy. I do agree that when the results are known they could and should be published. Is there any reason for privacy if you are nominated, elected, but choose not to accept? I don't think so. We want *everyone* to accept. Or should I go ahead and publish the list of people who are being recommended to the board as PMC members [probably a day or so after a [RESULT] on the pmc list just in case there are arguments over the results]. Yes - once we get the list complete (based on acceptance)... Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Differences
On Jan 14, 2004, at 7:08 PM, Ted Husted wrote: On Wed, 14 Jan 2004 09:00:31 -0500, Andrew C. Oliver wrote: I understand why you came here to ask this, but its not really a good place to ask (its more of an administrative list). You'd be better going and asking each of the projects (who will probably send you links to their website). Generally these messages devolve into flamebait because each project feels very passionate about their approach (enough to devote real time to developing it in fact) so asking them all in a room together what's the difference is well...often not pretty. Actually, this used to be the place where people could ask questions like this, and chat about everything under the Java sun. A while back, we co-opted the General list for use as the PMC public list. And subscribes to General have been falling every since. Less than a third of what they once were. Perhaps once most of the Committers are on the PMC list, we can move the administrative nonsense there again, and let the General list be the General list again :) +1 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Project Proposal
On Jan 8, 2004, at 1:12 PM, Chad Meadows wrote: Hi Danny, After reading some replies and further review, I am going to attempt to get this project hosted on IBM's developerworks Open Source site first. Once we can then establish a community of interest, then at that later time it may be better to evaluate this project as a potential member of Jakarta. When the project does become available, I will inform everyone on this list. That's a great approach, IMO. And as for the velocity bits, please come over to velocity-land and discuss with us. If appropriate for general use, we should talk. geir Thanks, Chad Meadows, Software Engineer Research Triangle Park T/L 526-2894 [EMAIL PROTECTED] image.tiffDanny Angus [EMAIL PROTECTED] image.tiff image.tiff Danny Angus [EMAIL PROTECTED] 01/08/2004 04:11 AM Please respond to Jakarta General List image.tiff To: Jakarta General List [EMAIL PROTECTED] cc: Subject: Re: New Project Proposal Chad, I am an IBM employee who has developed a new type of framework Please first read:http://jakarta.apache.org/site/newproject.html also readhttp://incubator.apache.org/ You might consider approching the incubator project (subscribe to [EMAIL PROTECTED]) I would certainly suggest it as the best next step for you. You might consider contributing this to jakarta-commons. Alternatively you might also consider approaching one of the existing Jakarta sub-projects if you believe that there might be benefit in creating a joint project combining the two things, or even of simply donating and joining an existing sub-project. Jakarta has a high bar for entry of new sub-projects, higher still since we have been encouraged by the ASF board to flatten the structure of Apache. This doesn't mean that we are unable or unwilling to consider new sub-projects but it does mean that we might have to work hard to justify it. One final word of advice, Apache is not sourceforge, and whilst we do welcome new projects it will require you to convince people of its worth and you would do well to find someone who can champion your cause and do some evangelising on your behalf. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi! ted. This footnote also confirms that this email message has been swept for the presence of computer viruses. *** *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Jan 3, 2004, at 9:53 AM, Andrew C. Oliver wrote: Everything is back on the private list again. Odd to discuss including more people in the PMC while excluding them from the discussion. Oh, quit it. Discussing individual people should be done in private to let people speak freely and avoid potential embarassment of those being discussed. geir -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
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 development team). But, in due course, the PMC that made them a committer also makes them a member. When our community elected all of our committers, it was with the understanding that they were the ones with binding votes, that they were the decision makers, that the Jakarta Committers were, in practice, the Jakarta PMC. In my humble opinion, it is the duty of the PMC to now ratify the decisions our community has already made. Since we now know that the PMC is *not* a steering committee and is in fact the active managers of the codebase, we are obligated to finish the job our community started: give the committers the legal rights and responsibility that we always believed they already had. Make the committers the PMC, because they are the only true PMC that we have ever had. Each and every one of our committers have earned their stripe. They have all proven to the community that they are thoughtful, responsible self-starters capable of managing our codebase on the community's behalf. These are the individuals that have been creating, maintaining and releasing the products we all cherish. These are the individuals that have been doing the true work of the PMC. Where things have gone wrong, they have gone wrong because we were still using a bootstrap PMC that excluded all but a few of our decision makers. I'm sure that there are Jakarta committers that would be unwilling to serve on a bootstrap PMC, but serving on a true, inclusive PMC may be a different matter. 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. But 'nuff said, I have a release to co-manage :) -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 29, 2003, at 10:17 AM, 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/ Because the PMC would consist of those doing the active management (i.e. the active, interested committers) , we have things covered. All active committers should be interested or else they wouldn't be active committers. Please - interested in participating on the PMC. Oversight is not some otherwordly task to be conducted by an elite subset of our committers. IP oversight is something *every* decision-maker should be thinking about *every* time they commit a line of code. Consensus oversight is something *every* decision-maker should be thinking about *every* time they post to the DEV list. If committers aren't thinking about this now, it's only because they have no reporting requirements to remind them. Ted, we all agree. Our community has already decided who its decision-makers should be: the committers. The Jakarta PMC doesn't need to second-guess the Jakarta community. We simply need to ratify the choices the community, in its wisdom, has already made. Moving forward, we may want to distinguish between newbie committers and the silver-haired PMC members. But, as it stands, when each of these committers were selected, they were selected to be *the* decision-makers. They were selected to do what the PMC does: actively manage the codebase. We should trust the judgment of our community, let each committer decide for themselves, and then Jakarta be whatever Jakarta wants to be. 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. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
+1! On Dec 29, 2003, at 6:01 PM, Danny Angus wrote: We should trust the judgment of our community, let each committer decide for themselves, and then Jakarta be whatever Jakarta wants to be. +1 I totally agree, and I would hope that no one seriously holds any other view. Concern about oversight has been flagged as an issue for us to address and we are duty bound to explore the ways in which we can achieve this. I would hope that by debating the issue we are bringing it to the wider attention of our community, and disseminating fact and opinion (perhaps, indeed, for a third or fourth time) which will help to inform the actions of every commiter and PMC member and bring us closer to our goal without any radical or authoritarian steps being required. Frankly I would regard either step as being at best a partial failure, and at worst potentially more damaging to the community than any failure to _quickly_ resolve the situation. I still believe that by continuing to have an open debate we are making progress, and I hope that others can see how frank and honest examination of the various opinions and potential directions is in itself vital to bind and re-unify the project and engage the whole community in shaping our mutual future. At the end of the day (Oh I hate it when I say that!) the most important asset we have is each other, and we have nothing to keep us here apart from the attraction of a healthy community, it is not bylaws or oversight or promotion that should be the focus of our efforts to restore some balance, rather it should be the community, and through the actions of a united community we will achieve the technical requirements of procedure and oversight in much the same way that a healty community will produce high quality software with very little management effort required. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 9:39 AM, Stephen Colebourne wrote: There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. The board isn't hassling. They have valid concerns that they know we are working on, and they are even helping. This doesn't mean we are out of the woods by any means, but we're not being hassled. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. Background info: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges Stephen PROPOSAL The Jakarta PMC shall proactively encourage subprojects to reach Top Level Project (TLP) status. It shall do this by - drawing up a list of advantages that TLP status brings - explaining the effect of the ASF only recognizing Jakarta on a subproject's rights - documenting the process, by receiving advice from recent new TLPs - produce a draft template board resolution for creating a TLP - clearly identifying board meeting dates for TLP creation - proactively encouraging proposal then vote on developer lists - setting a timefame of 3 months for the votes In order to respect current reality, voters on each dev list shall be those of committer and PMC member status who have made recent contributions, with the exact list to be determined by the dev list. -1 from me I fully support and respect sup-projects deciding on their own to leave Jakarta and be a TLP if they feel it's better for their community and code, but I see no reason for the PMC to make it their purpose on life to encourage them. Seems rather pointless. You might as well just disband Jakarta and save everyone time. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
On Dec 28, 2003, at 8:43 AM, Ted Husted wrote: * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and No, it doesn't. We need to put as many as possible, hopefully all, but it's not required to be all. We can also have people that aren't committers on the PMC. * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. Erm, I'm not so sure that this needs to be legislated like this. If anyone reading this message agrees, or disagrees, please respond to the As it ever were proposal under another thread. Let's see if we can build a consensus and then create and maintain a solution that works. IMHO, the ASF Way *will* work if we let it; we've just never tried to let it. I don't think that anyone is debating if the ASF works. I think we all know it does. I think we disagree what the ASF Way is - I think it simply requires inclusive participation on the PMC of those willing to feel responsible for more than just the code they are working on, namely project direction and oversight. Thus, the PMC does not necessarily mean forced 100% committer participation, although that percentage is the goal, nor does it mandate strict reporting schedules and reporting content and format. I do believe that if we continue on the way already started - ensuring CLAs, putting as many active Jakarta committers on the PMC as are interested, educating them as to their oversight role, then we would be in a much healthier position and able to then grapple with the day-to-day PMC process. Until we achieve the former, the latter is somewhat of a intellectual game. As you like to point out, we all are adults working for the best interest of the organization. Please work with us on this. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 10:50 AM, Noel J. Bergman wrote: Geir, I agree with everything that you said, except one. You have the idea that when a project moves to TLP status it leaves Jakarta, and that saddens you. In the above sentence, there is one correct statement : .. when a project moves to TLP status, it leaves Jakarta. (this is a correct and true statement) and one sort-of correct statement : ... and that saddens you. As it's bitter-sweet - it's good to see projects come out of Jakarta and continue to grow, and it's sad to see them leave, like when leaving a friend after a visit. What really saddens me is the idea of chasing them out the door. You said the same thing when Logging was promoted, and Ceki tried to reassure you that it wasn't going far. I was 100% supportive of logging going, and hope to see it prosper. However, it did go. :) Although I concur that projects that been promoted to TLP status have reduced their ties somewhat with Jakarta, that need not be the case. If you want Jakarta to be an active community hub, it can be so without a monolothic PMC. Jakarta will always have a PMC. Unless the board changes the Jakarta PMCs responsibilities, the PMC will be responsible for the code and communications of Jakarta. We may allow other Apache projects to have links and resources on our website, for example, but as it is the Jakarta PMC legally required to oversee such resources and activities, it's entirely up to us. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were (draft 2)
Jakarta from a place that is supposedly governed by an other wordly elite to a place that practice minimum threshold meritocracy -- both socially and legally. Today our social order is out-of-synch with our legal status. This proposal legalizes what already happens in practice. * It provides a forum where ALL the decision makers can discuss oversight (not just a chosen few). AND, * It puts reporting in the lap of the decision-makers for each product, which ensures it stays on the *decision-makers* radar, and is not pushed up to some body that cannot possible oversee our products. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) geir On Dec 28, 2003, at 11:13 AM, Ted Husted wrote: On Dec 28, 2003, at 8:43 AM, Ted Husted wrote: * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and No, it doesn't. We need to put as many as possible, hopefully all, but it's not required to be all. We can also have people that aren't committers on the PMC. * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. Erm, I'm not so sure that this needs to be legislated like this. If anyone reading this message agrees, or disagrees, please respond to the As it ever were proposal under another thread. Let's see if we can build a consensus and then create and maintain a solution that works. IMHO, the ASF Way *will* work if we let it; we've just never tried to let it. I don't think that anyone is debating if the ASF works. I think we all know it does. I think we disagree what the ASF Way is - I think it simply requires inclusive participation on the PMC of those willing to feel responsible for more than just the code they are working on, namely project direction and oversight. Thus, the PMC does not necessarily mean forced 100% committer participation, although that percentage is the goal, nor does it mandate strict reporting schedules and reporting content and format. I do believe that if we continue on the way already started - ensuring CLAs, putting as many active Jakarta committers on the PMC as are interested, educating them as to their oversight role, then we would be in a much healthier position and able to then grapple with the day-to-day PMC process. Until we achieve the former, the latter is somewhat of a intellectual game. As you like to point out, we all are adults working for the best interest of the organization. Please work with us on this. geir -- Geir Magnusson Jr 203-247-1713(m) [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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 11:26 AM, Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] What really saddens me is the idea of chasing them out the door. To use an analogy, its like being the parents of a family, where the children, aged from 4 to 40, are all living at home. It strikes me that it isn't healthy for that 40 year old to be living at home, expecting his parents to do the washing, feed him and make his bed. Instead, the good parent should be gently enabling the child to set out on their own in the next phase of their life. Sometimes letting go is the hardest part of being a parent. It's a good analogy, but makes the assumption that the Jakarta PMC will do for the sub-projects whatever is analogous to the care for children - washing, feeding and bed making. In fact (from my POV anyway), the Jakarta PMC has done no such thing in the past, and should do no such thing in the future. [Some proposals seem to want to enforce bed-making and ironing, but I don't think we should do that...] All we're trying to do is get the PMC populated w/ as many committers as possible, educated as to what oversight means, to satisfy the oversight requirements of the ASF.That's not something to take lightly, but it doesn't mandate additional process, control and procedure either. The board or ASF by-laws require no such scaffolding. Things will continue to be community-centered and decisions community-led. Sub-projects still govern their own activities. The PMC - composed of all the sub-projects - just makes those activities legal, in line w/ the oversight requirements of the ASF, and w/ proper education of the PMC members, helps catch problems. By becoming a TLP, a sub-project has changed nothing other than remove some antiquated-and-should-be-changed Jakarta charter restrictions, and removed itself from the larger community that is Jakarta. And yes, I recognize that people don't believe me about the last point. :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
No worries. I was just truly baffled. geir On Dec 28, 2003, at 11:59 AM, Ted Husted wrote: Mea culpa. I'm trying a new mail client and managed to press the wrong buttons. Sorry for the confusion. -Ted. - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 11:19:04 -0500 Subject: Re: Indemnification of the PMC Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 1:42 PM, Noel J. Bergman wrote: Geir Magnusson Jr. wrote: it's good to see projects come out of Jakarta and continue to grow, and it's sad to see them leave, like when leaving a friend after a visit. I understand. And I understand why you view Jakarta that way. Why do you not feel that Jakarta could be an active community hub, as has been the subject of several discussions? I just don't think it will happen. It will be a website at best, and a bad website at worst. As an example, look at the difference between Jakarta Commons to Apache Commons. Jakarta will always have a PMC. Unless the board changes the Jakarta PMCs responsibilities, the PMC will be responsible for the code and communications of Jakarta. The Jakarta PMC must oversee all codebases within its project. And it's website, the project websites, the mail lists and the usage of CVS. This implies that we should start by adding almost all currently active Committers to the Jakarta PMC. That's what we're trying to do. That is something the PMC could do, pro-actively, right now without further delay. Taking that action would mean that the majority of Committers would be on the PMC and general lists, improving the ability of the PMC to represent a true consensus of where Jakarta should go, and addressing a concern that we both share regard educating the Committers about their oversight responsibilities. But we've discussed this, and just glomming everyone wouldn't result in the best outcome as we want to make sure that people are explicitly signing up for project oversight, rather than being drafted to meet a quota. Personally, I don't feel that a 400+ person PMC overseeing dozens of codebases represents a truely functional solution, but we can give it a go. I can't see why not. The point of oversight is to catch the cases where things aren't right (i.e. code comes into the CVS that shouldn't w/o incubation) rather than continuously report when things are going well. It is my belief that subsequently more projects are going to want to seek TLP status, and that we will be all the better for it in terms of oversight and direct participation. So the question remains whether Jakarta should turn itself into a hub, so that when the subprojects acquire TLP status, they aren't forced to leave the community. I think a lot of what you say presupposed some sort of onerous additional work that comes from being a part of the Jakarta PMC. I would argue that it's no different - if you are providing oversight independently of Jakarta or part of Jakarta, it's the same amount of work. The question is how much value you place on Jakarta as a community versus Jakarta as a website. Again, I'll suggest that Jakarta Commons and Apache Commons might illustrate a bit about what I keep [unsuccessfully] trying to say. geir it's entirely up to us. Exactly. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 3:44 PM, Noel J. Bergman wrote: Costin Manolache wrote: I see jakarta more like a union ( EU-style ), were the different projects that joined are mature entities that choose to be part of jakarta ( and can choose to get out - all that's needed is a vote ). And the PMC role is to make sure the rules are respected Project maturity aside, I was with you up until the last sentence. Then you haven't seen what the EU has been up to :) Talk about over-regulation... The PMC is supposed to be performing the active management of one or more projects, not ensuring that other people are doing it. The PMC is not supposed to be a body of auditors. I see your analogy as describing self-managing bodies, i.e., projects with their own PMC, who operate a collective for the common good. Because the PMC would consist of those doing the active management (i.e. the active, interested committers) , we have things covered. geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 3:49 PM, Danny Angus wrote: -1 I don't think the PMC should be doing anything other than encouraging sub-projects to *consider* TLP at this stage. I don't even think they should do that. I don't think the PMC should take a position either way. I don't think there should be any communication that can even be confused as coming from the PMC. The proposal contains a number of detailed actions most of which I'd wholeheartedly support as they will help sub-projects to consider pro's and con's of promotion. However I think it is inappropriate to be talking about proactively encouraging proposal then vote. I would much rather that individuals who are active participants in the sub-project reach this stage, or don't, without having being prompted by the PMC. For the record I think that many sub-projects would benefit from promotion, but not all of them, but I think the process would be made much harder is the sub-project is hustled into applying before the participants are really comfortable with the nature and consequences of the change. And I think that once we have the PMC enlarged with all active, interested committers, these kinds of discussions and awareness will be a natural, open thing, not requiring any special schemes or campaigns geir d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 4:44 PM, Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] I think a lot of what you say presupposed some sort of onerous additional work that comes from being a part of the Jakarta PMC. I would argue that it's no different - if you are providing oversight independently of Jakarta or part of Jakarta, it's the same amount of work. Well this is a key point. I believe that now I am a Jakarta PMC member I have direct responsibility for ALL subprojects. Given the breadth of Jakarta this is a ridiculous position. So, it is more work. Much more work. For example, I have spent much less time coding in the last 4 weeks. And thats just plain wrong. We need to get that view corrected, because there is *nothing* that states that every member of the PMC is *directly* responsible for ever part of every code, doc, mail list and CVS usage in Jakarta, the key word is directly. Think about it. How could this possibly work in ANY ASF project of any useful size? You couldn't do a Commons TLP (be it A-C or J-C) if every participant was directly and personally responsible for every shred of activity. Here is what the ASF bylaws say : Subject to the direction of the Board of Directors, the chairman of each Project Management Committee shall be primarily responsible for project(s) managed by such committee, and he or she shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible A reasonable person should *not* read this to mean the PMC chair is directly, actively responsible in that he or she must read every commit, watch ever mail list, and see every site and wiki change - rather he or she is able and required to organize the day-to-day management as he or she sees fit (subject to board approval) such that all code, site, mail and wiki's are covered by active, responsible oversight. In the event that the management does *not* do this, the chair is responsible, but that's a huge difference from the 'every shred' model. Therefore I would think that given we have coverage of more than one committer per sub-project on the PMC, and those committers understand the oversight role and are actively performing that role, then the Jakarta PMC is compliant with the requirements of the ASF, is scalable, and puts minimal additional responsibility on those on the PMC. Isn't that reasonable? If I'm not careful, I'll go crazy like Robert. So I may choose to leave the PMC. Others will too, either actually resign, or just ignore it. Oversight is NOT increased - the basic approach of sign 'em up is flawed. sign 'em up is flawed, but not for the reason above (which I think is simply a misunderstanding on your part.) It's flawed because we can't assert that those tasked with oversight (of their projects) on behalf of the ASF as PMC member is doing their job is they didn't ask to do it and/or be trained to do it. I first floated the 'deputize them all' approach on the PMC list a while ago, and I'll be the first to say that I was wrong. The question is how much value you place on Jakarta as a community versus Jakarta as a website. The communities are the subprojects. And the subprojects together are also a community. I'm not the only one that recognizes this. Again, I'll suggest that Jakarta Commons and Apache Commons might illustrate a bit about what I keep [unsuccessfully] trying to say. Sorry, but I don't get you. A-C was a board invention. If it didn't exist then J-C would be able to TLP cleanly. Perhaps you need to explain more. In fact, perhaps you should set out in a separate thread as to where you see Jakarta in 3-6 months time. I'll be happy to do the latter. As for the former: A-C was a board invention, as you note, and I think a well-intentioned one. However, after 14 months, it has a single codebase (a http client written in C). J-C was a 'bottom-up' effort of multiple people in the Jakarta community from many *different* sub-projects that self-organized, debated independently (and incessantly) about the charter, presented the proposal to the PMC, had it approved and then rolled up their sleeves and got to work, with the resulting vibrant, productive community. The fact that participants from multiple sub-projects were the force behind J-C (and not the PMC or the board) to me validates my assertion that Jakarta as a whole is also a community. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
I'll try to be brief. I agree w/ you - I don't want to have to watch ever project. I'm also not interested in endless debate. I'm also not interested in legislation, process or overbearing procedure. And I'm not interested in breaking up Jakarta. All I want to do is get CLAs signed and maximize participation on the PMC that covers all projects to satisfy the ASF oversight requirements. My only concern about Lucene (to use your example) is that the code that comes into the ASF's CVS is free from any problems of provenance, and that the releases are done with the support of the Lucene community, and I would be comfortable w/ that if I knew that the active participants of the Lucene community were on the PMC and understood what the PMC does. (Note that we are not advocating any layer of management separate from the codebase, and have not had that to date.) As I think that your view of your responsibilities as a PMC members is mistaken. I'll ask for a clarification of the responsibilities from someone outside of Jakarta w/ no stake in this debate. I too have no interest in being forced to be involved w/ any project other than those I choose to participate in. geir On Dec 28, 2003, at 7:05 PM, Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] We need to get that view corrected, because there is *nothing* that states that every member of the PMC is *directly* responsible for ever part of every code, doc, mail list and CVS usage in Jakarta, the key word is directly. As a PMC member, I should care whether there is a new Tapestry release, or a new Lucene committer. These are PMC votes (or should be). But I don't care (especially ;-). Thus there is a tension between my mandated responsibility and my actual interests. This aspect of 'do I care' is key. I read every vote on J-C, I may not choose to vote (since adding lots of +0's wastes space), but I care about the release or new committer. But I don't care about Lucene. Not one jot. Yet I have equal responsibility for it. This just isn't right. All I have heard from the original ASF projects indicate to me that the PMC should represent one codebase and one tight community. Anything else leads to a layer of management separate from the codebase (aka Jakarta PMC). All the current debates exist because we have a layer of management which we do not need. These debates waste vast amounts of time and energy. Thus PMC members are given the choice: - debate/manage continuously and don't code, or - code and ignore the PMC I'm unusual in that I'm bothering putting any effort at all into the former. It won't be long before I'll give up and do the latter. Your POV will win on the PMC because everyone else has better things to do than argue incesantly. Therefore I would think that given we have coverage of more than one committer per sub-project on the PMC, and those committers understand the oversight role and are actively performing that role, then the Jakarta PMC is compliant with the requirements of the ASF, is scalable, and puts minimal additional responsibility on those on the PMC. Isn't that reasonable? No. What you are arguing for is just not human nature. As long as there is a PMC away from the dev list, with other people from the dev list, with other responsibilities and issues, people will not associate with it. People look after what they own, and don't care about what they don't own. They may be on the PMC in name, but that simply isn't enough. It really isn't. The fact that participants from multiple sub-projects were the force behind J-C (and not the PMC or the board) to me validates my assertion that Jakarta as a whole is also a community. The question that we cannot know the answer to (without a time machine) is whether the same result would have occurred if Jakarta had not existed. ie. Is J-C a product of Jakarta, or a product of the need for shared Java code. You believe its the former, I wasn't around so can't really comment, however I see no great reason why exactly the same J-C couldn't have occurred without Jakarta. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were (draft 2)
nothing of significance. It changes everything. It turns Jakarta from a place that is supposedly governed by an other wordly elite to a place that practice minimum threshold meritocracy -- both socially and legally. Today our social order is out-of-synch with our legal status. This proposal legalizes what already happens in practice. * It provides a forum where ALL the decision makers can discuss oversight (not just a chosen few). AND, * It puts reporting in the lap of the decision-makers for each product, which ensures it stays on the *decision-makers* radar, and is not pushed up to some body that cannot possible oversee our products. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 6:05 PM, Noel J. Bergman wrote: Geir Magnusson Jr. wrote: you haven't seen what the EU has been up to :) Talk about over-regulation... LOL :-) OK, so it is a bad analogy. I don't believe that either Costin or I live in the EU. I don't either. I live in Connecticut, USA. I was always suspicious that something was amiss trying to integrate proud countries with long individual histories, but it was confirmed the first time I had to schelp from Terminal 4 to Terminal 3 at Heathrow just so I could pick up the bus to Reading, which used to stop at all 4 terminals, but stopped going to terminal 4 because EU regs said the total trip was too long. The whole thing is something like an hour. :/ You also can't get soft cheese at a reasonable temperature in a restaurant under EU regs. They must keep them cold until being served. Ug. The PMC is supposed to be performing the active management of one or more projects, not ensuring that other people are doing it. The PMC is not supposed to be a body of auditors. I see your analogy as describing self-managing bodies, i.e., projects with their own PMC, who operate a collective for the common good. Because the PMC would consist of those doing the active management (i.e. the active, interested committers) , we have things covered. As I've said, let's do it. Get them on. And then see which projects decide to form their own PMC. The issue I was commenting on is not to lose a sense of community with those projects who choose to form their own PMC. True. geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scalability and oversight (Was: Just in case you're curious)
On Dec 27, 2003, at 1:39 PM, Santiago Gala wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El lunes, 22 dici, 2003, a las 16:32 Europe/Madrid, Geir Magnusson Jr. escribió: You are free to do what you want. Is this then about personal google hitcount? To the risk of re-starting a extinguishing discussion, I think google (or any outsider looking) plays an important role here, but not in the personal hitcount sense. I'll simply note that as you didn't quote what I was responding to, some readers unfamiliar with the thread might incorrectly assume that this was about an effort to keep this from being an open discussion. No one wanted to keep this from being an open discussion. It was first suggested by Peter a while ago, and I think everyone was in agreement. The issue was trying to get some organization and planning around a complicated subject before bringing it public. I think openness of product *and* process is the only thing that makes us scalable and fault-tolerant, when comparing Apache with more traditional organizations. I fully support openness, but I'll also note that a bit of organization and planning go a long way. And there are plenty of traditional closed organizations that do just fine due to planning and organization, such as IBM and Microsoft. Scalable because big groups of people can coordinate, even if they don't give specific input or they were not there while the decision was taken. Yep, all helped by a bit of planning and organization. Fault tolerant because the public audit trail left in CVS and mailing lists makes it easy for third party observers (or interested parties) to spot any error in oversight. Yep, all helped by a bit of planning and organization. Note that 'CVS' and 'mailing lists' are two examples of planning and organization. If we go to the cathedral versus bazaar metaphor, nothing beyond a small group conversation remains private in the bazaar. So, if some merchant down there is selling cheaper, notice propagates fast. Same if some merchandise is faulted. Maybe. I'll note that the most successful OSS projects I've seen also had a strong individual or group of individuals that helped via (you can guess what's coming...), ...a bit of planning and organization. Apache httpd, linux, emacs, hibernate, mysql, the list goes on... Same w/ Jakarta. There have always been a strong group of people guiding the sub-projects and the project overall. What we are trying to do now is increase that group, or better, recognize those that are doing it already, and conforming to legal structure needed by the ASF. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
On Dec 24, 2003, at 12:11 PM, Costin Manolache wrote: 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. My current position hasn't changed. We should try to include 100% of Jakarta committers, but recognize that we won't find that number who are willing to assume the oversight responsibility of being on the PMC. This isn't surprising, and is what other projects like httpd experience as well. And I agree, it must be a deterministic process - not a sweep. 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. I don't understand why he's going about it this way. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Exactly - lets not overdo this with too much process. Lets just get people who have genuine interest onto the PMC, covering the project(s) they work on, and then keep growing. geir On Dec 24, 2003, at 2:46 PM, Henri Yandell wrote: 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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - 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]
Indemnification of the PMC
Here is the clearest description I've found. It's by Roy Fielding, ex chair and board member of the ASF, and from all appearances, extremely knowledgeable in these matters. It was posted here : http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=2642 Indemnification is a promise by the corporation to pay the legal expenses of an *individual* if that *individual* becomes subject to criminal or civil proceedings as a result of their actions under a role identified by the corporation, as long as such person acted in good faith and in a manner that such person reasonably believed to be in, or not be opposed to, the best interests of the corporation. In other words, a member is only indemnified for their actions as a member (not much). A director or officer is only indemnified for their actions as a director or within the scope of their mandate as an officer. A PMC member is indemnified under the category of who is or was serving at the request of the corporation as an officer or director of another corporation, partnership, joint venture, trust or other enterprise and only to the extent of that enterprise (the project). A committer who is not a PMC member is not authorized by the corporation to make decisions, and hence cannot act on behalf of the corporation, and thus is not indemnified by the corporation for those actions regardless of their status as a member, director, or officer. Likewise, we should all realize and understand that the ASF's ability to indemnify an individual is strictly limited to the assets held by the ASF. Beyond that, we are on our own as far as personal liability. It is a far better defense that an outside entity cannot successfully sue an individual for damages due to a decision made by a PMC, so it is in everyone's best interests that all of the people voting on an issue be officially named as members of the PMC (or whatever entity is so defined by the bylaws). So in summary, a PMC member is indemnified for activities done on behalf of the corporation. I think that this would be limited to the official activities of the PMC - things done on behalf of the board for the ASF, such as oversight and releases - and not general day-to-day committer activities, such as technical discussion and personal code commits. Of course, that will probably need to be clarified too. However, the key thing to remember is that the indemnification is only up to the limit of the ASFs resources, which isn't much. So try to keep the litigation to a minimum :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
Oh, and thanks to Noel for the links... On Dec 23, 2003, at 6:49 AM, Geir Magnusson Jr. wrote: Here is the clearest description I've found. It's by Roy Fielding, ex chair and board member of the ASF, and from all appearances, extremely knowledgeable in these matters. It was posted here : http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=2642 Indemnification is a promise by the corporation to pay the legal expenses of an *individual* if that *individual* becomes subject to criminal or civil proceedings as a result of their actions under a role identified by the corporation, as long as such person acted in good faith and in a manner that such person reasonably believed to be in, or not be opposed to, the best interests of the corporation. In other words, a member is only indemnified for their actions as a member (not much). A director or officer is only indemnified for their actions as a director or within the scope of their mandate as an officer. A PMC member is indemnified under the category of who is or was serving at the request of the corporation as an officer or director of another corporation, partnership, joint venture, trust or other enterprise and only to the extent of that enterprise (the project). A committer who is not a PMC member is not authorized by the corporation to make decisions, and hence cannot act on behalf of the corporation, and thus is not indemnified by the corporation for those actions regardless of their status as a member, director, or officer. Likewise, we should all realize and understand that the ASF's ability to indemnify an individual is strictly limited to the assets held by the ASF. Beyond that, we are on our own as far as personal liability. It is a far better defense that an outside entity cannot successfully sue an individual for damages due to a decision made by a PMC, so it is in everyone's best interests that all of the people voting on an issue be officially named as members of the PMC (or whatever entity is so defined by the bylaws). So in summary, a PMC member is indemnified for activities done on behalf of the corporation. I think that this would be limited to the official activities of the PMC - things done on behalf of the board for the ASF, such as oversight and releases - and not general day-to-day committer activities, such as technical discussion and personal code commits. Of course, that will probably need to be clarified too. However, the key thing to remember is that the indemnification is only up to the limit of the ASFs resources, which isn't much. So try to keep the litigation to a minimum :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] ORO 2.0.8 maintenance release
+1
On Dec 23, 2003, at 8: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.
This vote will last until the end of Saturday 27th, 2003 (72 hours
minus the Christmas holiday). In accordance with
http://jakarta.apache.org/site/decisions.html, at least three binding
+1 votes are required for this vote to pass and the number of +1 votes
must exceed the number of -1 votes. Non-PMC members are encouraged
to cast their non-binding votes (please indicate your vote is
non-binding to facilitate vote tabulation).
RELEASE INFORMATION:
The 2.0.8 release will be a maintenance release incorporating the
following
changes since the 2.0.7 release made in January (taken from
http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content-
type=text/plain):
o examples moved to an examples package and com.oroinc migration tool
moved to tools package.
o Fixed bug whereby compiling an expression with
Perl5Compiler.MULTILINE_MASK wasn't always having the proper effect
with respect to the matching of $ even though
Perl5Matcher.setMultiline(true) exhibited the proper behavior. For
example, the following input
aaa bbb \n ccc ddd \n eee fff
should produce bbb , ddd , and fff as matches for both the
patterns \S+\s*$ and \S+ *$ when compiled with MULTILINE_MASK.
Perl5Matcher was only producing the correct matches for the second
pattern, producing only fff as a match for the first pattern
unless setMultiline(true) had been called. This has now been fixed.
o Fixed embarrassing bug whereby an expression like (A)(B)((C)(D))+
when matched against input like ABCDE would produce matching groups
of: A B null D instead of A B CD C D.
These changes have been available to the public in the CVS repository
for testing since May 2003. There are no outstanding/unresolved issue
reports for the code.
Daniel Savarese (dfs.apache.org) will serve as the release manager for
this release. A release announcement will be sent to
{oro-dev,oro-user,[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr 203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Sign those CLAs!
Members of the Jakarta Community : With the privilege of committership in the ASF comes the requirement that each committer sign a document called the Committer License Agreement, or CLA. The CLA is a legal agreement between you, the committer, and the ASF in which you state that the contributions that you make to the ASF in form of code, documentation, etc is your work that you are free to contribute, and that you are granting an unfettered copyright license to the ASF for that work. The purpose is to allow the ASF to be sure that the code that it offers to the world is, to the best of it's knowledge, free of questions about source and ownership. To that end, it is required that every committer in Jakarta has a signed CLA on file with the ASF. In the past, we have been negligent in ensuring this document was completed and filed, and wish to immediately rectify the situation for the ASF. This is a simple procedure, generally requiring just a few minutes of your time to fill out and mail or fax to the ASF administrative office. It will be greatly appreciated if this could be taken care of immediately. To check to see if you have a CLA on file, look here : http://www.apache.org/~jim/committers.html or http://www.apache.org/~jim/projects.html and find your name on either. If it is in italics, it means the CLA has been received and is on file. If not, please get one in. If you don't have a CLA on file, the CLA form can be found here : http://www.apache.org/licenses/cla.txt and a PDF version can be found here : http://www.apache.org/licenses/cla.pdf We will be sending out gentle reminders during the upcoming week or so for those that don't have a CLA on file, so the sooner the better as there will be less follow-up work for other Jakarta community members to do - after all, this is your responsibility and we're all volunteers. If there are any questions or problems, please bring them to this list ([EMAIL PROTECTED]). If you have private concerns, because of employment or otherwise, feel free to post to the Official Jakarta State Sekrets List ([EMAIL PROTECTED]), send a private message to one or more of the knowledgeable people here on general@, post to the board list ([EMAIL PROTECTED]) - fair warning - readership is bigger than just the board - or to one of the board members or officers directly. This is an important subject, and people will give help if asked. Thanks for looking into this serious matter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 22, 2003, at 7:27 AM, Vic Cekvenich wrote: BIG SNIP Geir Magnusson Jr. wrote: ... sensitive things should be on the PMC list, and non-sensitive things should be on the general@ list. /end Geir What could be something that is sensteive in an open source community? This is new direction. Gray areas should be well exposed. If you are ashamed of it, don't do open source community. There are lots of things. Committer votes, for example, are considered a sensitive issue. Inter-personal disputes. If you would have been fair with your attribution, you would have included what I then said next, namely that I felt it sensitive because of the confusion that it sews. My hope was for us to get our act together before we approached the rest of the community, and do it as a group. IOW, simply to get a handle on how we approach the community to make things clear and non-confusing. For a developer ... lets have some code in open, and the bad code we will just have in a encrypted jar. Is this open source? What do I mean by that: ASF used(?) to be Libreterian: If you want code to do something, commit the code to do it. ASF used(?) to be run by commiters. Now some are trying to develop rulling class, that is carving out roles for itself and rules to legislate iteligence and integrity for commiters, but does not committ itself?. What happend to emritius commiters? People who did not CVS a chunk of code in a while lose vote rights and their berucrat office. The people that are vocal on berucracy are same people I wonder where have they CVSed latelly. Vic, if you've been paying ANY attention, you'd know that what we are trying to do is just the opposite - get *every* committer in Jakarta onto the PMC, *eliminating* this needless boundary. Please re-read. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 22, 2003, at 8:05 AM, Tetsuya Kitahata wrote: On Mon, 22 Dec 2003 07:38:54 -0500 Geir Magnusson Jr. wrote: What could be something that is sensteive in an open source community? This is new direction. Gray areas should be well exposed. If you are ashamed of it, don't do open source community. There are lots of things. Committer votes, for example, are considered a sensitive issue. Inter-personal disputes. I agree. Also, I think [PROPOSAL] As it ever were mail was very reasonable. However, just one question came to my mind. Have The Committer Votes (I mean, [VOTE] in to elect new committer) to be taken place at Jakarta PMC list? ... This is very sensitive issue (maybe causes inter-personal dispute), i guess. Could you please explain more? Committer votes haven't taken place on the Jakarta PMC list. PMC member votes have, but that's a different thing. Here in Jakarta (as well as other projects, I assume), the sub-projects do committer votes in public. Some people outside of Jakarta feel that this is improper, and should be done in private to ensure that open discussion can happen in a way that doesn't hurt peoples feelings. I can see both sides of this - do it in public because it's a good pat on the back for a person to see fellow community members supporting him or her, but on the other hand, it would be a shame for people to be unable to say how they feel about a proposed committer and have that POV understood by others w/o possibly hurting the feelings of the person being voted on. I hope this is something we take up when we have this PMC issue sorted out. geir Thanks in advance. -- Tetsuya. ([EMAIL PROTECTED]) P.S. Vic, if you've been paying ANY attention, you'd know that what we are trying to do is just the opposite - get *every* committer in Jakarta onto the PMC, *eliminating* this needless boundary. Well said. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
I realize that arguing with you on this will have no effect, but I want to keep working to extinguish the meme you keep trying to plant. IIRC, the thread in play at the time was my note to ask the opinion of all PMC members re the CLA signing, to make sure that it was a clear message we all wanted to go out with. IRRC, you never even responded to it. Further, IIRC, there was broad consensus that things should be public (I think it was Peter's first nudge), and we were working that direction. geir On Dec 21, 2003, at 11:04 PM, Andrew C. Oliver wrote: Well, saying please and asking nicely had no effect. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Martin van den Bemt [EMAIL PROTECTED] Organization: mvdb.com Reply-To: Jakarta General List [EMAIL PROTECTED] Date: 22 Dec 2003 01:53:20 +0100 To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Just in case you're curious Sorry to hear you didn't understand my mail at all If that is the way a PMC member communicates, I can never be part of that PMC. Mvgr, Martin On Sun, 2003-12-21 at 23:10, Andrew C. Oliver wrote: Now the conversation is here, that is the solution. You're welcome. -Andy - 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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
You are free to do what you want. Is this then about personal google hitcount? On Dec 21, 2003, at 11:06 PM, Andrew C. Oliver wrote: I think the problem isn't the private list, on which we will continue to do work, such as voting, but follow up. geir Heads up, FYI, except where I feel the situation absolutely mandates it, I will be voting/discussing here. While I'm not sure I agree, out of courtesy, I will vote privately for: * PMC nominations/discussion * legally precarious issues * things too likely to cause me to get slashdotted. I favor openness, but the peanut gallery isn't helpful. Pointedly, I will not discuss the organization, structure, software, etc. of Jakarta on [EMAIL PROTECTED] I will discuss it here. This is my personal choice. I choose to work in the open. I choose to be googled. I volunteered for it in fact. -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Geir Magnusson Jr. [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] Date: Sun, 21 Dec 2003 07:35:45 -0500 To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Just in case you're curious On Dec 21, 2003, at 3:51 AM, Santiago Gala wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El domingo, 21 dici, 2003, a las 02:35 Europe/Madrid, Henri Yandell escribió: On Sat, 20 Dec 2003, Santiago Gala wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El jueves, 18 dici, 2003, a las 15:52 Europe/Madrid, Henri Yandell escribió: http://jakarta.apache.org/site/whoweare.html lists the PMC members up until the previous addition of 20 or so. That list has to go to the board etc and I plan to add them to the list as soon as I see them appear on the board's list [in the committers/ cvs module]. I have just discovered I'm listed as PMC member in the web page. When was I appointed? is there no notification to elected people? Ack. Sorry. Completely my mistake. I added you along with three others, thinking you'd been part of a batch vote with them. Instead your vote was separate one. This is the kind of problems that happen with private lists. I think the problem isn't the private list, on which we will continue to do work, such as voting, but follow up. geir -- Geir Magnusson Jr 203-247-1713(m) [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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 22, 2003, at 10:31 AM, Danny Angus wrote: While closing out everyone else. Like those who are not yet committers. I certainly think that increasing the size of the PMC makes it easier for things to get discussed on the PMC list, but if people care (and you do for one) about visibility the very nature of things mean that it won't happen for long before someone starts to get obstreperous. Just to save everyone the trip to dictionary.com : ob·strep·er·ous Pronunciation Key (b-str p r- s, b-) adj. 1. Noisily and stubbornly defiant. 2. Aggressively boisterous. I know from the past that you'd favour a fully open process, but we don't have that. I don't think this should _necessarily_ be a social experiment, in open management, this isn't a political project its about software. No one wants things unnecessarily private. The less the better. The less organizational conversation the better - more tech, more community. This stuff is tiring :) geir d. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. From: Geir Magnusson Jr. [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] Date: Mon, 22 Dec 2003 07:38:54 -0500 To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Just in case you're curious On Dec 22, 2003, at 7:27 AM, Vic Cekvenich wrote: BIG SNIP Geir Magnusson Jr. wrote: ... sensitive things should be on the PMC list, and non-sensitive things should be on the general@ list. /end Geir What could be something that is sensteive in an open source community? This is new direction. Gray areas should be well exposed. If you are ashamed of it, don't do open source community. There are lots of things. Committer votes, for example, are considered a sensitive issue. Inter-personal disputes. If you would have been fair with your attribution, you would have included what I then said next, namely that I felt it sensitive because of the confusion that it sews. My hope was for us to get our act together before we approached the rest of the community, and do it as a group. IOW, simply to get a handle on how we approach the community to make things clear and non-confusing. For a developer ... lets have some code in open, and the bad code we will just have in a encrypted jar. Is this open source? What do I mean by that: ASF used(?) to be Libreterian: If you want code to do something, commit the code to do it. ASF used(?) to be run by commiters. Now some are trying to develop rulling class, that is carving out roles for itself and rules to legislate iteligence and integrity for commiters, but does not committ itself?. What happend to emritius commiters? People who did not CVS a chunk of code in a while lose vote rights and their berucrat office. The people that are vocal on berucracy are same people I wonder where have they CVSed latelly. Vic, if you've been paying ANY attention, you'd know that what we are trying to do is just the opposite - get *every* committer in Jakarta onto the PMC, *eliminating* this needless boundary. Please re-read. geir -- Geir Magnusson Jr 203-247-1713(m) [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] *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited
Re: [PROPOSAL] As it ever were
I don't think that crossposting would be good keep it here On Dec 22, 2003, at 4:52 PM, Tetsuya Kitahata wrote: Hello, folks. I am a moderator of three -dev lists in jakarta. What should I do next? Forwardin' this Pro-forma to each -dev lists? T.I.A. -- Tetsuya. ([EMAIL PROTECTED]) On Sun, 21 Dec 2003 21:07:26 -0500 (Subject: Re: [PROPOSAL] As it ever were) Geir Magnusson Jr. wrote: This is what I proposed some weeks ago. I think you would serve the community well if you also posted a summary of pros and cons that we had discussed. On Dec 21, 2003, at 6:14 PM, Ted Husted wrote: Re: Proposal to grandfather Active Committers to Jakarta subprojects as PMC Members. As it stands, most Jakarta committers have assumed that they already have the rights, privileges, and responsibilities granted PMC members. (Mainly because it was written that way in the Jakarta bylaws). When all these committers were elected, it was with the understanding they had binding votes and oversight responsibility, as stated by the original Jakarta bylaws. It could be said that we have been electing PMC members, rather than only committers, all along, without realizing it. Following our original bylaws and practices, there is no such thing as a committer without the rights and responsibilities of PMC membership. Accordingly, a stipulation of becoming (or remaining) a committer to a Jakarta subproject can said to be PMC membership, as it is described by the ASF bylaws. To complete the process we've already begun, I suggest a [VOTE] be brought on each [EMAIL PROTECTED] list to nominate the list of its active committers to the PMC. This vote will also serve as notice to committers who wish to opt-out. To bootstrap the process, the current moderator of each DEV list can be asked to bring the vote and report the result. If necessary, a new moderator can be installed by the Chair. The moderator of each dev list will also act as the PMC steward for the subproject. The list moderator is suggested since that individual is already suppose to be monitoring the list where this activity occurs. The steward will have the responsibility of immediately reporting any new committers/PMC members elected to a subproject, so that they can be affirmed by the chair and notice given the board. All PMC members (which is to say all active committers to jakarta-* CVS repositories) will be subscribed to the PMC list, which will be a required list for PMC membership, like [EMAIL PROTECTED] The PMC business for each subproject will continue to take place on its own dev list. The steward for each project will report to the [EMAIL PROTECTED] list the status of his or her subproject, covering such points as: * What code releases have been made? * Legal issues: * Cross-project issues: * Any problems with committers, members, etc? * Plans and expectations for the next period? The chair can then summarize these reports for presentation to the board. Effectively, each dev list becomes a sub-committee of the PMC. (Divide and conquer.) The list moderator/steward becomes the subcommittee's secretary, with the additional responsibility of summarizing the result of our ongoing meetings. As appropriate, the steward or any PMC member can bring up oversight issues to the PMC list. Routine matters, such as releases, can be approved by the PMC members who are committers to a given subproject. So long as the usual 3+ quorum is met, there would be no reason to bring routine votes before the [EMAIL PROTECTED] list. Of course, the result would be tabulated on the steward's report, which *is* published to the [EMAIL PROTECTED] list. -Ted. Pro-forma [VOTE] It has come to our attention that the Committers to a Jakarta subproject must also be members of the Jakarta Project Management Committee to have binding votes. To complete the legal process, the current PMC is asking each subproject to nominate it's active committers to the PMC. Since we have never supported the idea of non-voting committers at Jakarta, and only PMC members have binding votes, if a committer is unwilling to serve on the Jakarta PMC, we will be unable to continue to extend write access to any jakarta-* CVS to that individual. Each PMC member will also be subscribed to the Jakarta PMC list. *However, all subproject business can continue to occur on this DEV list as always!* In the future, we anticipate that the PMC list will be very low-volume. (Really, we do!) The only change is that the owner of the DEV list must also serve as the PMC steward for the subproject. The steward must submit monthly status reports for the project and immediately report any new Committers to the PMC list. But, other than that, it will be business as usual. Accordingly, we ask that the Committers to this subproject nominate the following individuals to the Jakarta PMC. Please check all that apply. [ ] $committer Any committer who wishes to opt-out may notify the Jakarta chair
Re: Just in case you're curious
On Dec 22, 2003, at 6:23 PM, Dain Sundstrom wrote: Larry, I'm surprised that no one answered this (at least that I saw). From what I understand, ASF believes that those on PMC have liability protection from the ASF because the PMC members are acting on behalf of the organization. Further is it seems that the ASF does not believe this protection extends to those not in the PMC (this is my personal logical conclusion based on statements around why someone would like to join a PMC). This protection is usually referenced when people talk about IP, and I'm not sure if it extends to other areas. I'm not aware of an official statement on this, but it would be nice to have one. I did respond. As I understand it, here is no protection for PMC members except for the chair, if he or she was acting on behalf of the corporation in good faith. And if you don't know Larry, he's a well-known attorney specializing in OSS matters. geir Happy Holidays -dain /* * Dain Sundstrom * Partner * Core Developers Network */ On Dec 21, 2003, at 9:08 PM, Lawrence E. Rosen wrote: No, that is not correct. The point of having most committers on the PMC is not to keep discussions out of google. The point of getting them on the PMC is so that the ASF can legally protect them, and so that they are legally empowered to participate in the decisions that govern the project. Would someone please explain what protection committers expect from ASF? And what legal empowerment is being granted? /Larry Rosen - 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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 22, 2003, at 7:07 PM, Dain Sundstrom wrote: On Dec 22, 2003, at 5:58 PM, Geir Magnusson Jr. wrote: On Dec 22, 2003, at 6:23 PM, Dain Sundstrom wrote: Larry, I'm surprised that no one answered this (at least that I saw). From what I understand, ASF believes that those on PMC have liability protection from the ASF because the PMC members are acting on behalf of the organization. Further is it seems that the ASF does not believe this protection extends to those not in the PMC (this is my personal logical conclusion based on statements around why someone would like to join a PMC). This protection is usually referenced when people talk about IP, and I'm not sure if it extends to other areas. I'm not aware of an official statement on this, but it would be nice to have one. I did respond. As I understand it, here is no protection for PMC members except for the chair, if he or she was acting on behalf of the corporation in good faith. Sorry missed your reply. From what I have seen there are vastly differing opinions on this matter (from ranking people in ASF). Anyway, it would be nice to see something official on this matter, but it is a legal matter and therefore unlikely to happen (at least anytime soon ;) Feel free to send them to me. I'm interested. I'll be happy to report back a summary or correction. And if you don't know Larry, he's a well-known attorney specializing in OSS matters. I know Larry. He used to a company I used to do business with. Ah Sorry. :) geir -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 21, 2003, at 5:03 PM, Andrew C. Oliver wrote: You go discus your private matters wherever you like, I'd like to talk about open source projects and am quite willing to do so in the open. And you know there's a difference. :) What that we've discussed so far has been SSSooo sensitive? The recipe to the secret Jakarta Eggnog? I thought Jon took that with him... I think it is: Lots of expensive Bze Cheap store-bought eggnog There... Impeach me. I've divulged the state secrets. -Andy That's the point of getting as many people as are seriously interested in the subject on the PMC. Then all can participate, and if we discuss something sensitive (as defined by the discusser), it doesn't all have to be on Google. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just in case you're curious
On Dec 19, 2003, at 12:56 AM, Rainer Klute wrote: On Thu, 18 Dec 2003 10:23:16 -0500 Harish Krishnaswamy [EMAIL PROTECTED] wrote: 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. That's just as I see it. Discussions should definetly take place HERE. That's the point of getting as many people as are seriously interested in the subject on the PMC. Then all can participate, and if we discuss something sensitive (as defined by the discusser), it doesn't all have to be on Google. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
On Dec 19, 2003, at 2:27 PM, Ted Husted wrote: Harish Krishnaswamy wrote: 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. I'd say it the other way around. The ASF is a collection of communities that create and maintain codebases. To obtain infrastructure support and some legal protection, these communities donate the copyright of its software and ownership of its brand to the Foundation. In order to provide legal protection and watchdog its copyright, the board assigns a vice president to oversee the project. A committee is also convened to assist the VP with oversight. I think this is mostly right, and I say mostly because it's legally precise, but in practice, the community tends to be there first, rather than be convened later, and the community also tends to suggest to the board the individual they wish to 'oversee' (meaning the PMC chair). The board doesn't always accept the community's recommendation, though, and indeed the selection of chair is legally the board's sole assignment, as you way. Since the committee is formed by a resolution of the board, its members are eligible for legal protection in the event of a lawsuit. I don't believe this is correct, although it will require someone else to give a definitive answer. (I've been playing a bit in the legal sandbox re some ASF-related issues, so I've been paying attention to this...) Indemnification is granted for directors, officers and members of the corporation (the ASF), or serving at the request of the corporation in some way. Thus, the PMC chair, as an officer of the corporation is protected, but not all PMC members. However, the structure of the ASF is such that the ASF is the holder of copyright and owner of the code, which provides a level of protection for committers. Also, since the committee is the only formal body created by the board, only the votes of committee members are considered binding. In the normal course, most or all of the committers are also committee members. (Jakarta being an anomaly.) 100% correct [SNIP] A very subtle concept is that the ASF doesn't actually own the codebase. The codebase belongs to its community, and under the Apache License, that community can always vote with its feet. Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. I believe that this isn't right - the ASF does own the codebase via the copyright, and the codebase is licensed at no cost to any entity that is willing to agree to the terms of the license. That entity, community or otherwise, cannot remove that license or change it unilaterally. I think that my understanding of these issues has been clarifying over the last several months due to my JCP work. This stuff always is hard for us non-lawyers. To that end, as I am not a lawyer, all that I said above could be completely wrong :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
