[PROPOSAL] Two community proposals
I started to write a long email on the problems in Jakarta, on umbrellas, on the lack of a Jakarta community and existence only of subcommunities and on how it should be there is no Jakarta Xxxx, you are members of Jakarta - not a subproject; but you've heard it all before. So, proposal: - Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. - Comments? The only negative I have for 1) is that I like to use the commit lists to see who is on which subproject (for 3 PMC member oversight checking), but that is a flawed idea anyway. The real way is to see who is voting on issues (especially releases) for that project. If it's an inactive project, the real way is to ask the -dev mailing list for 3 PMC replies else the subproject gets mothballed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subproject Charters
I notice that Commons and HTTP Components both have charters. Other subprojects may have them and I've just missed in my very quick look. Do these serve any purpose? Are they a legacy of the days when we tried to create an ASF-like structure within Jakarta to organize things? Any reason not to go ahead and kill these subproject charters? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Representing project inactivity on the site
I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? What labels should we use? I suggest: * Delete Alexandria. It's at the same level as the java-* CVS stuff, ancient history to be forgotten. * ECS, ORO, Regexp to be moved to a label of Inactive. * Others to be raised as questions separately and voted on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On 05.03.2006, at 20:21, Henri Yandell wrote: I started to write a long email on the problems in Jakarta, on umbrellas, on the lack of a Jakarta community and existence only of subcommunities and on how it should be there is no Jakarta Xxxx, you are members of Jakarta - not a subproject; but you've heard it all before. So, proposal: - Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. So a Commons committer can commit to e.g. BCEL and Hivemind without knowing the code bases? H That doesn't sound right to me :-/ TBH Jakarta feels less as one community ...but more like an umbrella. Do you want to change that? cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: Representing project inactivity on the site
Hola, The word we've used in the past for this type of scenario is dormant, although inactive is just as good IMHO. We've left the link up but made the front page something like this: http://jakarta.apache.org/watchdog/index.html, whose text we spent a good time considering and debating. And generally, +1 to doing the Watchdog thing with all inactive/dormant projects such as you pointed out. Yoav On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? What labels should we use? I suggest: * Delete Alexandria. It's at the same level as the java-* CVS stuff, ancient history to be forgotten. * ECS, ORO, Regexp to be moved to a label of Inactive. * Others to be raised as questions separately and voted on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Senior Architect 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]
Re: Subproject Charters
Hola, Do these serve any purpose? Are they a legacy of the days when we tried to create an ASF-like structure within Jakarta to organize things? I think the answer to the 2nd question is yes. Any reason not to go ahead and kill these subproject charters? The Commons is about having a place for existing committers to easily and quickly play with stuff that may or may not become actual ASF projects. If we kill the Commons charter, we either need to make sure an alternative place is available for that purpose, or that all members agree to take their playing elsewhere, e.g. SourceForge. -- Yoav Shapira Senior Architect 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]
Re: Representing project inactivity on the site
Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Or does Dormant/Inactive imply Mature/Stable? S. On 05/03/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, The word we've used in the past for this type of scenario is dormant, although inactive is just as good IMHO. We've left the link up but made the front page something like this: http://jakarta.apache.org/watchdog/index.html, whose text we spent a good time considering and debating. And generally, +1 to doing the Watchdog thing with all inactive/dormant projects such as you pointed out. Yoav On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? What labels should we use? I suggest: * Delete Alexandria. It's at the same level as the java-* CVS stuff, ancient history to be forgotten. * ECS, ORO, Regexp to be moved to a label of Inactive. * Others to be raised as questions separately and voted on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Senior Architect 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: Subproject Charters
On 05/03/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, Do these serve any purpose? Are they a legacy of the days when we tried to create an ASF-like structure within Jakarta to organize things? I think the answer to the 2nd question is yes. Or they may be a way of trying to avoid feature creep. Any reason not to go ahead and kill these subproject charters? The Commons is about having a place for existing committers to easily and quickly play with stuff that may or may not become actual ASF projects. If we kill the Commons charter, we either need to make sure an alternative place is available for that purpose, or that all members agree to take their playing elsewhere, e.g. SourceForge. ?? did you mean Sandbox - or the whole of Commons ?? -- Yoav Shapira Senior Architect 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: Representing project inactivity on the site
Hi, You're right, that's a good distinction to make, because dormant/inactive is not always the same as mature/stable. That's why we wrote the explanation on the Watchdog page with regards to servlet specification versions. On the ORO page, I might imagine a notice saying this project is dormant but considered mature/stable, and not much work is being done now because regex's are natively in supported in JDK 1.4. Or something to that effect... Yoav On 3/5/06, sebb [EMAIL PROTECTED] wrote: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Or does Dormant/Inactive imply Mature/Stable? S. On 05/03/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, The word we've used in the past for this type of scenario is dormant, although inactive is just as good IMHO. We've left the link up but made the front page something like this: http://jakarta.apache.org/watchdog/index.html, whose text we spent a good time considering and debating. And generally, +1 to doing the Watchdog thing with all inactive/dormant projects such as you pointed out. Yoav On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? What labels should we use? I suggest: * Delete Alexandria. It's at the same level as the java-* CVS stuff, ancient history to be forgotten. * ECS, ORO, Regexp to be moved to a label of Inactive. * Others to be raised as questions separately and voted on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira Senior Architect 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] -- Yoav Shapira Senior Architect 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]
Re: Subproject Charters
Hola, ?? did you mean Sandbox - or the whole of Commons ?? Sandbox, and apologies for the confusion. Sometimes things are so crystal clear in one's mind, and yet different stuff gets typed out ;) -- Yoav Shapira Senior Architect 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]
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. I don't like the idea having a lot of discussion on one mailing list and then loosing all that context by having votes on a different mailing. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Am Sonntag, den 05.03.2006, 15:03 + schrieb sebb: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Yes, I second that. Inactive, dormant etc. sound negative while mature or stable leave a good impression. And it is indeed a big difference if a project isn't developed any further because it is all a pile of junk or because it is complete, optimized and couldn't be improved. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Public key fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E signature.asc Description: This is a digitally signed message part
Re: [PROPOSAL] Two community proposals
On Sun, 5 Mar 2006, Torsten Curdt wrote: On 05.03.2006, at 20:21, Henri Yandell wrote: I started to write a long email on the problems in Jakarta, on umbrellas, on the lack of a Jakarta community and existence only of subcommunities and on how it should be there is no Jakarta Xxxx, you are members of Jakarta - not a subproject; but you've heard it all before. So, proposal: - Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. So a Commons committer can commit to e.g. BCEL and Hivemind without knowing the code bases? H That doesn't sound right to me :-/ Any reasons? What's the difference between an ORO guy being able to commit to OpenPGP and a Lang guy being able to commit to OpenPGP? Said ORO committer is able to -1 the OpenPGP release if they should so wish (presuming they're on the PMC). TBH Jakarta feels less as one community ...but more like an umbrella. Do you want to change that? Yes. Umbrellas don't work well at Apache and umbrellas who promote their active participants out all the time are down-right suicidal - however umbrellas who dont promote large active participants out should form their own foundation. XML and WS are both facing the same types of issues - XML have hit on a nice solution of promoting subprojects out while retaining them within the federation while WS are killing subprojects and merging them. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
Hi! So a Commons committer can commit to e.g. BCEL and Hivemind without knowing the code bases? H That doesn't sound right to me :-/ What's the difference between an ORO guy being able to commit to OpenPGP and a Lang guy being able to commit to OpenPGP? Said ORO committer is able to -1 the OpenPGP release if they should so wish (presuming they're on the PMC). I too think this helps to keep a project alive and I don't expect that a developer of another project makes big structural changes to such a projects, just small quick-fixes. At least as long as a developer take the liability seriously. This is as much more true when we speak about dormant or stable but not under development projects. If we move them to an excubator or whatever name it is, we should open them to every committer. This might be the last chance for those project to get restarted again. e.g. POI is widely used - but rarely developed. Now it is required to removed barriers to hopefully get them running again. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Rainer Klute wrote: Am Sonntag, den 05.03.2006, 15:03 + schrieb sebb: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Yes, I second that. Inactive, dormant etc. sound negative while mature or stable leave a good impression. And it is indeed a big difference if a project isn't developed any further because it is all a pile of junk or because it is complete, optimized and couldn't be improved. That's one of the problems, we have many different messages: Alexandria - Dead. Unreleased. No future. Delete. BCEL - In need of a bugfix release, design-wise ASM is preferrable. BSF - Would have been in the inactive category, now active again. ECS - Tiny user base. No interest in a 2.0. Unfashionable designwise. JCS - Seems very inactive. Unsure on userbase. Keeps getting forked. (ehcache, jcache/fkache). Regexp - Tiny user base. Dead development. ORO - JDK 1.2 engine of choice. Inactive development - there is no reason to start development up again currently. Slide - Too inactive to complete its TLP move. Turbine - Umbrella of its own. Hard to know what the activity is in each, but the mailing list isn't that active. Commons - Active, but definite areas of inactivity. Taglibs - Inactive, RDC Taglib is about it for activity there. Velocity - At least DVSL is dead - unsure about tools. POI - Seems to be fighting inactivity. Finding a label to match the above messages is tricky; inactive development seems to be the only one that fits. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: Finding a label to match the above messages is tricky; inactive development seems to be the only one that fits. How about a project is in hibernation. In other words no future developement is expected unless the enviroment for that project changes. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I notice that Commons and HTTP Components both have charters. Other subprojects may have them and I've just missed in my very quick look. Do these serve any purpose? Are they a legacy of the days when we tried to create an ASF-like structure within Jakarta to organize things? They were originally created to define the (sub)projects we were creating, and they still serve that purpose. If you get rid of the charter, where would you propose that we define the purpose and scope of these projects? And what would you call that if it isn't a charter? Any reason not to go ahead and kill these subproject charters? Yes. See above. There needs to be some place where we state the official purpose and scope, and that isn't just some words that someone happened to use as a description on some page that's part of the site. Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I started to write a long email on the problems in Jakarta, on umbrellas, on the lack of a Jakarta community and existence only of subcommunities and on how it should be there is no Jakarta Xxxx, you are members of Jakarta - not a subproject; but you've heard it all before. So, proposal: - Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. What problem is this solving? I just don't see the need. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. I agree with Sandy on this one. The votes should stay on the relevant developer list. -- Martin Cooper - Comments? The only negative I have for 1) is that I like to use the commit lists to see who is on which subproject (for 3 PMC member oversight checking), but that is a flawed idea anyway. The real way is to see who is voting on issues (especially releases) for that project. If it's an inactive project, the real way is to ask the -dev mailing list for 3 PMC replies else the subproject gets mothballed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different flavours of done-ness. I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. -- Martin Cooper What labels should we use? I suggest: * Delete Alexandria. It's at the same level as the java-* CVS stuff, ancient history to be forgotten. * ECS, ORO, Regexp to be moved to a label of Inactive. * Others to be raised as questions separately and voted on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I started to write a long email on the problems in Jakarta, on umbrellas, on the lack of a Jakarta community and existence only of subcommunities and on how it should be there is no Jakarta Xxxx, you are members of Jakarta - not a subproject; but you've heard it all before. So, proposal: - Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. i think this is fine. it brings our practice more in line with the legal realities of the organization. it adds potential for greater cross-pollination and lower barriers to resuscitating dormant projects. it's true that most of us committers are myopic and do nothing with the greater freedom, but the potential is there for some to more easily serve the community and their own needs through this. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. if you want all non-private vote threads to be CC'ed to general@, that's fine, but they must happen on the dev lists as well. i believe there are many narrow, non-committer participants who give good feedback and non-binding support who do not subscribe to [EMAIL PROTECTED] i am extremely reluctant to give that up. - Comments? The only negative I have for 1) is that I like to use the commit lists to see who is on which subproject (for 3 PMC member oversight checking), but that is a flawed idea anyway. The real way is to see who is voting on issues (especially releases) for that project. If it's an inactive project, the real way is to ask the -dev mailing list for 3 PMC replies else the subproject gets mothballed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Rainer Klute wrote: Am Sonntag, den 05.03.2006, 15:03 + schrieb sebb: Might be worth distinguishing the Mature/Stable projects - e.g. ORO. [We're happily using that in JMeter] Yes, I second that. Inactive, dormant etc. sound negative while mature or stable leave a good impression. And it is indeed a big difference if a project isn't developed any further because it is all a pile of junk or because it is complete, optimized and couldn't be improved. That's one of the problems, we have many different messages: Alexandria - Dead. Unreleased. No future. Delete. BCEL - In need of a bugfix release, design-wise ASM is preferrable. BSF - Would have been in the inactive category, now active again. ECS - Tiny user base. No interest in a 2.0. Unfashionable designwise. JCS - Seems very inactive. Unsure on userbase. Keeps getting forked. (ehcache, jcache/fkache). Regexp - Tiny user base. Dead development. ORO - JDK 1.2 engine of choice. Inactive development - there is no reason to start development up again currently. Slide - Too inactive to complete its TLP move. Turbine - Umbrella of its own. Hard to know what the activity is in each, but the mailing list isn't that active. Commons - Active, but definite areas of inactivity. Taglibs - Inactive, RDC Taglib is about it for activity there. Velocity - At least DVSL is dead - unsure about tools. VelocityTools is very much alive. POI - Seems to be fighting inactivity. Finding a label to match the above messages is tricky; inactive development seems to be the only one that fits. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I notice that Commons and HTTP Components both have charters. Other subprojects may have them and I've just missed in my very quick look. Do these serve any purpose? Are they a legacy of the days when we tried to create an ASF-like structure within Jakarta to organize things? They were originally created to define the (sub)projects we were creating, and they still serve that purpose. If you get rid of the charter, where would you propose that we define the purpose and scope of these projects? And what would you call that if it isn't a charter? Any reason not to go ahead and kill these subproject charters? Yes. See above. There needs to be some place where we state the official purpose and scope, and that isn't just some words that someone happened to use as a description on some page that's part of the site. Why restrict a project? I missed the alternative on this email (it spun out of a Commons email) which is why don't we require these of all subprojects? Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? The Jakarta charter where it says Java (which in fact it doesn't say - might be a bit of an ommission). Here's the Commons Charter: *** 0) rationale history, then: A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. Each package will be managed in the same manner as a larger Jakarta product. bit about sandbox (2) identify the initial set of committers historical list ** If anything, that's a better Jakarta charter than the Jakarta charter and should be merged in - but there's very little to restrict the scope of Commons. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
BCEL - In need of a bugfix release, design-wise ASM is preferrable. Almost there :) ...still a few bugs to close cheers -- Torsten smime.p7s Description: S/MIME cryptographic signature
Re: Subproject Charters
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I notice that Commons and HTTP Components both have charters. Other subprojects may have them and I've just missed in my very quick look. Do these serve any purpose? Are they a legacy of the days when we tried to create an ASF-like structure within Jakarta to organize things? They were originally created to define the (sub)projects we were creating, and they still serve that purpose. If you get rid of the charter, where would you propose that we define the purpose and scope of these projects? And what would you call that if it isn't a charter? Any reason not to go ahead and kill these subproject charters? Yes. See above. There needs to be some place where we state the official purpose and scope, and that isn't just some words that someone happened to use as a description on some page that's part of the site. Why restrict a project? One of your big things right now - order and organisation. ;-) I missed the alternative on this email (it spun out of a Commons email) which is why don't we require these of all subprojects? I can't answer the question, but that would be fine with me. Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? The Jakarta charter where it says Java (which in fact it doesn't say - might be a bit of an ommission). OK, then what about a Java constraint framework? Here's the Commons Charter: *** 0) rationale history, then: A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. Each package will be managed in the same manner as a larger Jakarta product. bit about sandbox (2) identify the initial set of committers historical list ** If anything, that's a better Jakarta charter than the Jakarta charter and should be merged in - but there's very little to restrict the scope of Commons. Well, I see: * Written in Java. * Independent packages. * Intended for server-side. * Not frameworks. Those don't all apply to Jakarta as a whole, but they do all apply to Commons, and I, for one, do not want to lose those statements of scope and purpose. It's a charter, whether or not you want to call it one. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different flavours of done-ness. I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. I'm suggesting: Active Subprojects * Alexandria * BCEL * BSF * Commons * HiveMind * JMeter * Tapestry * Velocity Inactive Subprojects * Cactus * ECS * JCS * ORO * POI * Regexp * Slide * Taglibs * Turbine Though it's also obvious that I want all of the Commons components, Turbine components, Velocity components, Taglibs components and any other hidden away sub-sub-projects to be at the same level. Alexandria itself would just go into a trash-can - same place JServ went. -- All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Am Sonntag, den 05.03.2006, 16:08 -0500 schrieb Henri Yandell: Inactive Subprojects ... * POI ... No! POI is not inactive at all. I just committed a major enhancement a few days ago. Best regards Rainer Klute Rainer Klute IT-Consulting GmbH Dipl.-Inform. Rainer Klute E-Mail: [EMAIL PROTECTED] Körner Grund 24 Telefon: +49 172 2324824 D-44143 Dortmund Telefax: +49 231 5349423 Public key fingerprint: E4E4386515EE0BED5C162FBB5343461584B5A42E signature.asc Description: This is a digitally signed message part
Re: [PROPOSAL] Two community proposals
On Sun, 2006-03-05 at 12:22 -0800, Nathan Bubna wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. i think this is fine. it brings our practice more in line with the legal realities of the organization. it adds potential for greater cross-pollination and lower barriers to resuscitating dormant projects. it's true that most of us committers are myopic and do nothing with the greater freedom, but the potential is there for some to more easily serve the community and their own needs through this. +1 Commons committers voted in for their work on one project technically have access to other projects. This has not had any negative results as fa as I am aware, and it has lowered the barriers for those committers to become involved in other commons projects where appropriate. I've not seen any case where a committer made inappropriate changes to another project - and if it did happen, normal community oversight would pick that up. I would expect jakarta-wide commit privileges to work just as well as commons-wide. Re measuring community size of a project and determining *who* the community is, I agree that the committer list for that project isn't actually very effective. There are several possible measures I can see: * counting vote emails as mentioned by Henri * counting SVN commits to a particular project * inspecting the maven project.xml's committers section and then cross-checking whether the listed people are actively committing to ANY project (ie whether they are still around) * annual online survey that all committers are asked to complete, in which we indicate what projects we actively participate in. Cheers, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: Why restrict a project? One of your big things right now - order and organisation. ;-) Guess I don't see this as one that needs constraining - how a component/subproject does something - sure. What it's allowed to do - nope. Not as long as it falls within the larger Jakarta charter. I missed the alternative on this email (it spun out of a Commons email) which is why don't we require these of all subprojects? I can't answer the question, but that would be fine with me. Seems like unnecessary bureaucracy. Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? The Jakarta charter where it says Java (which in fact it doesn't say - might be a bit of an ommission). OK, then what about a Java constraint framework? If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons, +1 to Jakarta, but they're converging to both be a +1 if not too framework like. Here's the Commons Charter: *** 0) rationale history, then: A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. Each package will be managed in the same manner as a larger Jakarta product. bit about sandbox (2) identify the initial set of committers historical list ** If anything, that's a better Jakarta charter than the Jakarta charter and should be merged in - but there's very little to restrict the scope of Commons. Well, I see: * Written in Java. +1 to this in the Jakarta charter - though I'd probably say 'Written for Java'. Commons Daemon has C parts, but exists for the purposes of Java. * Independent packages. Common sense - assuming it means other people wouldn't use their packages, but fine to add to the Jakarta charter. If it means no dependencies, well we break this one a lot. * Intended for server-side. +1 to this in the Jakarta charter. We've always had this as a loose constraint. We don't interpret this as server-side though, rather we interpret it as not client-side. * Not frameworks. +1 to this in the Jakarta charter - we're heading that way. Those don't all apply to Jakarta as a whole, but they do all apply to Commons, and I, for one, do not want to lose those statements of scope and purpose. It's a charter, whether or not you want to call it one. So my disagreement is that I think it should apply to Jakarta as a whole - and is pretty close to doing so. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Rainer Klute wrote: Am Sonntag, den 05.03.2006, 16:08 -0500 schrieb Henri Yandell: Inactive Subprojects ... * POI ... No! POI is not inactive at all. I just committed a major enhancement a few days ago. *evil grin* I may have added a couple to that list that I know are active-ish to see if they pay attention to general@ :) Generally POI's mailing list is full of gump errors and bug reports, but there was a recent bit of discussion. I also don't pay attention to the svn checkins for poi but look for mail list discussion to indicate activity. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
Henri Yandell wrote: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. I'm +1 on this one. As others already pointed out, it would help to keep dormant/stable projects more active and would allow committers fixed small bugs on other projects. That's particular useful on commons sub-projects, as its components are used by many projects (for instance, I have submitted a couple of simple patches - including test cases - to Jelly, but they haven't been applied neither commented yet...). -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
Felipe Leme wrote: Henri Yandell wrote: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. I'm +1 on this one. As others already pointed out, it would help to keep dormant/stable projects more active and would allow committers fixed small bugs on other projects. That's particular useful on commons sub-projects, as its components are used by many projects (for instance, I have submitted a couple of simple patches - including test cases - to Jelly, but they haven't been applied neither commented yet...). Also +1, and for exactly this reason. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
I like #1 (removing svn restrictions). We occasionally identify bugs in the commons libraries used in Velocity - it'd be nice to be able to just go in and fix them. I'm mildly positive on all votes on general. A corollary of this would be to encourage everyone to sign up for general. Maybe put this in big letters on the Jakarta home page. It seems a good way to try out the one community idea, see if it fits. WILL On 3/5/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I started to write a long email on the problems in Jakarta, on umbrellas, on the lack of a Jakarta community and existence only of subcommunities and on how it should be there is no Jakarta Xxxx, you are members of Jakarta - not a subproject; but you've heard it all before. So, proposal: - Given that we are one project and that we should be acting as one community - I propose that we: 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. i think this is fine. it brings our practice more in line with the legal realities of the organization. it adds potential for greater cross-pollination and lower barriers to resuscitating dormant projects. it's true that most of us committers are myopic and do nothing with the greater freedom, but the potential is there for some to more easily serve the community and their own needs through this. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. if you want all non-private vote threads to be CC'ed to general@, that's fine, but they must happen on the dev lists as well. i believe there are many narrow, non-committer participants who give good feedback and non-binding support who do not subscribe to [EMAIL PROTECTED] i am extremely reluctant to give that up. - Comments? The only negative I have for 1) is that I like to use the commit lists to see who is on which subproject (for 3 PMC member oversight checking), but that is a flawed idea anyway. The real way is to see who is voting on issues (especially releases) for that project. If it's an inactive project, the real way is to ask the -dev mailing list for 3 PMC replies else the subproject gets mothballed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- ___ Forio Business Simulations Will Glass-Husain phone (415) 440-7500 x89 mobile (415) 235-4293 [EMAIL PROTECTED] www.forio.com
Re: Representing project inactivity on the site
Henri Yandell wrote: Inactive Subprojects * Cactus Cactus is more on a 'Hibernation' status; I agree there hasn't been activities in the last weeks, but we have some stuff planned (for instance, I should have relased Cactus 1.7.2 to fix the jboss-j2ee.jar issue, but couldn't do so yet...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On Sun, 5 Mar 2006, Will Glass-Husain wrote: I'm mildly positive on all votes on general. A corollary of this would be to encourage everyone to sign up for general. Maybe put this in big letters on the Jakarta home page. It seems a good way to try out the one community idea, see if it fits. To stir things a bit more :) We could go further and say that all non-technical discussions are on [EMAIL PROTECTED] All navel-gazing, all infrastructure style, all license questions etc. -dev lists would remain to discuss the actual code, bugfixes etc and would promote non-code issues up to the general mailing list. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Felipe Leme wrote: Henri Yandell wrote: Inactive Subprojects * Cactus Cactus is more on a 'Hibernation' status; I agree there hasn't been activities in the last weeks, but we have some stuff planned (for instance, I should have relased Cactus 1.7.2 to fix the jboss-j2ee.jar issue, but couldn't do so yet...) This is true of most of our inactive codebases - and it will stay that way if we let them wait quietly on their -dev lists for time to show up. I've screwed up in forgetting the jboss-j2ee jar issue; should be yelling at you guys to get that release done :) For something like this, it's essential that we're talking about it on general@ and not on cactus-dev. If something has been in Hibernation status for a period of time, the only real hope (imo) is to declare it inactive and see if that shocks the committers into doing something. I've meant to do something about my PGP problems for 2 years or so. It's only the embaressment of admitting that it's just a couple of evenings worth of work to fix them and a couple of USB keys at the supermarket that have kicked me into dealing with it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Will Glass-Husain wrote: I'm mildly positive on all votes on general. A corollary of this would be to encourage everyone to sign up for general. Maybe put this in big letters on the Jakarta home page. It seems a good way to try out the one community idea, see if it fits. To stir things a bit more :) We could go further and say that all non-technical discussions are on [EMAIL PROTECTED] All navel-gazing, all infrastructure style, all license questions etc. -dev lists would remain to discuss the actual code, bugfixes etc and would promote non-code issues up to the general mailing list. Great idea! Then I can unsub from general@ and avoid all the navel-gazing! :-) -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: I really shouldn't be sending multiple emails at the same time - you'll all jsut end up replying to one of them. However, itching while the itch is present. Alexandria is dead. We need to represent it as so on the site. Why? You're trying to save one mouse click? It's clear as day that it's dead as soon as you click on the link. ECS, ORO, Regexp are inactive development-wise - represent - site. Slide, POI, Turbine, JCS seem pretty inactive - should we represent such? Why do we need to do this on the front page? Each site can say whatever it needs to, since, as you indicated in a subsequent message, there are many different flavours of done-ness. I think about the only person that needs such a summary on one page is you, Hen. ;-) And it's just one more thing to maintain that means updating the Jakarta site instead of the subproject site, which is backwards to me. I'm suggesting: Active Subprojects * Alexandria * BCEL * BSF * Commons * HiveMind * JMeter * Tapestry * Velocity Inactive Subprojects * Cactus * ECS * JCS * ORO * POI * Regexp * Slide * Taglibs * Turbine But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not - or maybe I don't, since it's open source and I could fix the problems myself, if I chose to. The people who care about active versus inactive are those on the PMC, and those are not the people we should be designing the Jakarta front page for. Though it's also obvious that I want all of the Commons components, Turbine components, Velocity components, Taglibs components and any other hidden away sub-sub-projects to be at the same level. Alexandria itself would just go into a trash-can - same place JServ went. -- All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. It should be what it is. As I just wrote in another message (on commons-dev, I think), you can't make a community into something other than what it has grown into organically. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. And there you have the nub of my objections to all this manipulation of communities. -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject Charters
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: Why restrict a project? One of your big things right now - order and organisation. ;-) Guess I don't see this as one that needs constraining - how a component/subproject does something - sure. What it's allowed to do - nope. Not as long as it falls within the larger Jakarta charter. It's not so much what it's allowed to do, as much as to define its purpose. Perhaps you see Velocity as a viable Commons component, but I don't. Nor do I think it would make sense for Digester to be part of Cactus, or Taglibs to be part of Slide. A well-defined scope is a good thing, and helps people understand what they're looking at. I missed the alternative on this email (it spun out of a Commons email) which is why don't we require these of all subprojects? I can't answer the question, but that would be fine with me. Seems like unnecessary bureaucracy. It's not bureaucracy. See above. Say some Prolog constraint framework decided it wanted to be part of Commons. Where would you point them to explain that that's not what Commons is about? The Jakarta charter where it says Java (which in fact it doesn't say - might be a bit of an ommission). OK, then what about a Java constraint framework? If it's large: -1 to Commons, -1 to Jakarta. If it's tiny +0 to Commons, +1 to Jakarta, but they're converging to both be a +1 if not too framework like. I specifically chose a framework for my example because we have long stated that frameworks should not live in Commons, and that is stated in our charter. Are you saying you want to change that now, to allow frameworks as Commons components? I so, -1 from me. -- Martin Cooper Here's the Commons Charter: *** 0) rationale history, then: A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. Each package will be managed in the same manner as a larger Jakarta product. bit about sandbox (2) identify the initial set of committers historical list ** If anything, that's a better Jakarta charter than the Jakarta charter and should be merged in - but there's very little to restrict the scope of Commons. Well, I see: * Written in Java. +1 to this in the Jakarta charter - though I'd probably say 'Written for Java'. Commons Daemon has C parts, but exists for the purposes of Java. * Independent packages. Common sense - assuming it means other people wouldn't use their packages, but fine to add to the Jakarta charter. If it means no dependencies, well we break this one a lot. * Intended for server-side. +1 to this in the Jakarta charter. We've always had this as a loose constraint. We don't interpret this as server-side though, rather we interpret it as not client-side. * Not frameworks. +1 to this in the Jakarta charter - we're heading that way. Those don't all apply to Jakarta as a whole, but they do all apply to Commons, and I, for one, do not want to lose those statements of scope and purpose. It's a charter, whether or not you want to call it one. So my disagreement is that I think it should apply to Jakarta as a whole - and is pretty close to doing so. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
Hola, Martin, I agree with almost everything you've said, except this: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I I do care, a lot, as a user. Active means bugs are getting fixed, the mailing lists are a reasonable source for help, and if new standards become relevant or new features are requested by numerous, there's a good chance the product will evolve to comply with them. As a user who doesn't have Apache commit privilges and who doesn't want to fork a product just to use it, activity versus dormancy is a HUGE factor in choosing a product. Yoav -- Yoav Shapira Senior Architect 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]
Re: Representing project inactivity on the site
On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. It should be what it is. As I just wrote in another message (on commons-dev, I think), you can't make a community into something other than what it has grown into organically. Agreed - that's why I'm not JFDI as one piece of advice I've received suggests. I'm also trying to avoid it being manipulation - I could have pushed each item one at a time in most-likely-to-be-accepted order. That would have been a lot easier, but too machiavellian. Least I'm trying to not be doing that :) Thus emails about long term ideas etc. More confusing to the community, but less manipulative. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. And there you have the nub of my objections to all this manipulation of communities. Stepping further back than the community question - do you think the current Jakarta community of communities is healthy? Do you think there are ways that an umbrella (in the negative sense of the word) can continue to grow (in health rather than size) within the ASF? It's possible it's just me wanting to make the chair role a non-fulltime job. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, Martin, I agree with almost everything you've said, except this: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I I do care, a lot, as a user. Active means bugs are getting fixed, the mailing lists are a reasonable source for help, and if new standards become relevant or new features are requested by numerous, there's a good chance the product will evolve to comply with them. As a user who doesn't have Apache commit privilges and who doesn't want to fork a product just to use it, activity versus dormancy is a HUGE factor in choosing a product. You snipped out the part that explains what you quoted. ;-) What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not If you are saying that you wouldn't even try out a component that's marked as 'inactive', to see if it does what you need, then I think it would be a *huge* disservice to flag components as inactive right on the front page, because then people might not even look at them, even if they're done and would completely fit their needs. Marking a component as 'inactive' would then be the final nail in its coffin. -- Martin Cooper Yoav -- Yoav Shapira Senior Architect 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]
Re: Representing project inactivity on the site
On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: On Sun, 5 Mar 2006, Martin Cooper wrote: On 3/5/06, Henri Yandell [EMAIL PROTECTED] wrote: All (90%?) of the navel gazing comes down to one binary question. Should Jakarta be a community, or a community of communities. Are we Jakarta committers, or ORO committers. It should be what it is. As I just wrote in another message (on commons-dev, I think), you can't make a community into something other than what it has grown into organically. Agreed - that's why I'm not JFDI as one piece of advice I've received suggests. I'm also trying to avoid it being manipulation - I could have pushed each item one at a time in most-likely-to-be-accepted order. That would have been a lot easier, but too machiavellian. Least I'm trying to not be doing that :) Thus emails about long term ideas etc. More confusing to the community, but less manipulative. I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. Agreed - most/all of this will seem backwards if someone takes the view of community of communities as opposed to single community. And there you have the nub of my objections to all this manipulation of communities. Stepping further back than the community question - do you think the current Jakarta community of communities is healthy? Not completely, no. I don't follow all the pieces as closely as I believe you do, but gangrene has definitely set in in places. Taglibs is the example I'm most familiar with, but I believe that can be resolved by amputating the truly dead limbs and revitalising the remainder as part of the (eventually, I hope) forthcoming Jakarta Web Components subproject. (On the other hand, I suspect that part of the reason for the demise of Taglibs is because a lot fewer people are using JSP tags these days, having moved on to AJAX or JSF.) With many Jakarta subprojects having been around for some time, some of them are just more or less done, which leads to quiet spots in the community. I think that's fine - we need to recognise that most software projects don't go on forever (even if it can seem otherwise, sometimes ;), and most developers don't work on the same projects all of their lives. When the conversation slows or comes to an end on subproject X, we shouldn't assume the community is then unhealthy. Maybe it's just done, or people have moved on to a different technology, or whatever. Putting an old race horse out to pasture is a lot different than killing it. ;-) Do you think there are ways that an umbrella (in the negative sense of the word) can continue to grow (in health rather than size) within the ASF? In health, yes, and I think we're on that path. Shrinking in size and bringing the scale of subprojects closer together both help, and much of that has happened, with the big subprojects moving out to TLPs. Getting Web Components off the ground will also help. And in that same vein of collecting like components into Commons-ish sets, I believe that Stephen Colebourne's proposal for Jakarta Language Components would also help. Despite some pitfalls along the way, I believe the Commons model has worked well, and seeing that spread into Web Components and Language Components is great. -- Martin Cooper It's possible it's just me wanting to make the chair role a non-fulltime job. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Martin Cooper [EMAIL PROTECTED] wrote: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not - or maybe I don't, since it's open source and I could fix the problems myself, if I chose to. The people who care about active versus inactive are those on the PMC, and those are not the people we should be designing the Jakarta front page for. My thoughts exactly. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
Henri Yandell wrote: Given that we are one project and that we should be acting as one community I both agree and disagree with the premise. Jakarta is one community from an ASF point of view (not that important). Jakarta is many communities in reality (really important). Reality and practicality should drive our thoughts, not the ASF board. 1) Remove SVN restrictions, all Jakarta committers can commit anywhere in Jakarta, with the exception of the Commons-Sandbox as it allows Apache committers in general to commit. +0. I don't see any real downsides to this, as social factors will act as a suitable control. However, it doesn't strike me as a big issue. 2) All vote threads to occur on the general@ mailing list; or the pmc@ mailing list if deemed private. -1. This splits votes from code and community. Its just a bad idea. Instead we should say that votes *may* occur on jakarta-general if desired. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representing project inactivity on the site
On 3/5/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/5/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, Martin, I agree with almost everything you've said, except this: But why? If I'm a user looking for something to help me out in my development, I don't really care that much if it's active or not. What I I do care, a lot, as a user. Active means bugs are getting fixed, the mailing lists are a reasonable source for help, and if new standards become relevant or new features are requested by numerous, there's a good chance the product will evolve to comply with them. As a user who doesn't have Apache commit privilges and who doesn't want to fork a product just to use it, activity versus dormancy is a HUGE factor in choosing a product. You snipped out the part that explains what you quoted. ;-) What I care about is if it does the job. If there are problems with it, then I might care about whether it's active or not If you are saying that you wouldn't even try out a component that's marked as 'inactive', to see if it does what you need, then I think it would be a *huge* disservice to flag components as inactive right on the front page, because then people might not even look at them, even if they're done and would completely fit their needs. Marking a component as 'inactive' would then be the final nail in its coffin. i quite agree! -- Martin Cooper Yoav -- Yoav Shapira Senior Architect 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]
One community or many
Henri Yandell wrote: I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. It just seem to me to be impossible to imagine a commons-betwixt developer caring about velocity-tools, or a taglibs-foo developer caring about bcel. There is no community in common. In commons we care about a broad range of different projects. But the degree to which we care about components other than our own has reduced over time (roughly inverse proportional to the number of components). So yes, in the past I was gung-ho about commons taking over the whole of Jakarta. Now I recognise commons can barely manage itself, let alone any more projects. Size matters. (In fact, commons often behaves as multiple communities already. Its natural and organic. I'm embracing it by proposing Jakarta Language Components.) At some point a recognition needs to occur that hierarchy is not evil. We are all developers. We group things into hierarchies naturally. If you flattened all the turbine components on the home page of jakarta all you'd be doing is forcing the reader to group them. The turbine components will always 'belong to' Turbine. In summary, I believe we are many communities, not one. What unites us is our size, in that each individual community is too small to stand alone as a TLP. There is the *potential* to build a cross-Jakarta community in *addition* to our smaller communities, but it requires care and nurturing. Perhaps a single jakarta-user ML, or a forum are the places to start. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: One community or many
On 3/5/06, Stephen Colebourne [EMAIL PROTECTED] wrote: Henri Yandell wrote: I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. It just seem to me to be impossible to imagine a commons-betwixt developer caring about velocity-tools, or a taglibs-foo developer caring about bcel. There is no community in common. In commons we care about a broad range of different projects. But the degree to which we care about components other than our own has reduced over time (roughly inverse proportional to the number of components). So yes, in the past I was gung-ho about commons taking over the whole of Jakarta. Now I recognise commons can barely manage itself, let alone any more projects. Size matters. Yes, it does, and I think it's really important that we recognise that. Those of us who've been around since the inception of Commons, in particular, will hear the ring of truth in Stephen's words. Jakarta Commons was a much more cohesive and vibrant community in the early days, and there were indeed more committers per component, on average, than we have today. Now, while Commons has been growing like topsy, Jakarta as a whole has been shrinking, with several subprojects graduating into their own TLPs. That has been good for Jakarta, and for those subprojects. There's not much left that could logically go TLP, so we need to deal with what's left. I agree with Stephen's comments above that forcing everything that's left into a single group doesn't make sense. They really are different, and we should recognise that. (In fact, commons often behaves as multiple communities already. Its natural and organic. I'm embracing it by proposing Jakarta Language Components.) And I believe that is the way forward, especially for Commons. HttpClient blazed a path, and now we have Jakarta HTTP Components. We're about to create Jakarta Web Components, which will acquire pieces from Commons and Taglibs. So it makes perfect sense to take the group of components related to extending the Java language and form Jakarta Language Components out of that. The end result will be smaller, more cohesive, more vibrant communities than we have today. It's hard to imagine why that would be a bad thing! -- Martin Cooper At some point a recognition needs to occur that hierarchy is not evil. We are all developers. We group things into hierarchies naturally. If you flattened all the turbine components on the home page of jakarta all you'd be doing is forcing the reader to group them. The turbine components will always 'belong to' Turbine. In summary, I believe we are many communities, not one. What unites us is our size, in that each individual community is too small to stand alone as a TLP. There is the *potential* to build a cross-Jakarta community in *addition* to our smaller communities, but it requires care and nurturing. Perhaps a single jakarta-user ML, or a forum are the places to start. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: One community or many
On Mon, 6 Mar 2006, Stephen Colebourne wrote: Henri Yandell wrote: I'm not tied to any of the things I'm suggesting - except the strong belief that Jakarta as a community of communities cannot work. So I'm definitely in favour of more shared site and less individual site - I'm in favour of a flat Jakarta, both in terms of SVN acces and not allowing subprojects of subprojects (ie: Jakarta Velocity-DVSL, not Jakarta Velocity DVSL); I'm in favour of sharing the decisions - rather than having a slice of the PMC informing the main PMC of their decision. It just seem to me to be impossible to imagine a commons-betwixt developer caring about velocity-tools, or a taglibs-foo developer caring about bcel. There is no community in common. In commons we care about a broad range of different projects. But the degree to which we care about components other than our own has reduced over time (roughly inverse proportional to the number of components). So yes, in the past I was gung-ho about commons taking over the whole of Jakarta. Now I recognise commons can barely manage itself, let alone any more projects. Size matters. (In fact, commons often behaves as multiple communities already. Its natural and organic. I'm embracing it by proposing Jakarta Language Components.) At some point a recognition needs to occur that hierarchy is not evil. We are all developers. We group things into hierarchies naturally. If you flattened all the turbine components on the home page of jakarta all you'd be doing is forcing the reader to group them. The turbine components will always 'belong to' Turbine. In summary, I believe we are many communities, not one. What unites us is our size, in that each individual community is too small to stand alone as a TLP. There is the *potential* to build a cross-Jakarta community in *addition* to our smaller communities, but it requires care and nurturing. Perhaps a single jakarta-user ML, or a forum are the places to start. Generally, I'm not in disagreement with the above. The Turbine point is wrong - JCS, Maven and others came out of Turbine - the Velocity components will always be Velocity based, but Turbine components seem to do well at being distinct entities. Grouping hierarchies is good. It'll be a shame to enforce mutual exclusiveness, but it'll be hard to have groupings as a tagging if we divide mailing lists along those lines. Multiple mailing lists is quite simply necessary due to the weakness of our communication tools. Commons taking over Jakarta is about the Commons ideas becoming the Jakarta ideas. Java Component would be put into the charter. SVN would be open, not closed. Unified mailing lists would be aimed for as much as possible. And yes, I agree that you can't ignore the fact that Jakarta is a set of multiple communities. The important word is disjoint - Jakarta is a disjoint set of communities, we don't have enough overlap. Commons is a (erm...opposite of disjoint) set of communities. Your Language Components suggestion will not split the community, there will still be a high level of overlap. Commons shows that we will always have multiple communities - but that we need to keep the overlapping high. The biggest dangers to overlap are: * Subprojects of subprojects. Thus my attempt to get us to classify Jakarta as a large collection of components - even if we group them for communicative needs. So in SVN we would not reflect the groupings - either in terms of url or authentication. Officially we would not group them, they are all components of Jakarta. Basically anything we can come up with to not create islands that won't be damaging. * Autonomic mailing lists. Lists on which all discussions concerning the project occur. TLP discussions, discussions like these, legal issues, even votes should be taking place in front of the whole community and not the tiny subset. I know there will be cross-thread issues, and people may be unhappy with the noise of a single list (but given the general noise level of these issues I don't think it would be that noisy a list) - but it is critical to keep even a community of communities running. Both Stephen and Martin have mentioned HTTP Components. Let's not forget that Commons HTTPClient was an utter failure. We moved it to its own dev list due to its own noise, and it became its own community with zero overlap. If all we do is rearrange Jakarta into new islands, we'll have failed again. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Web Components
(feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
