Re: [PROPOSAL] Two community proposals
In message [EMAIL PROTECTED], Henri Yandell writes: 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. I'm okay with both suggestions because it maps directly to how I thought things were supposed to work (i.e., all committers in a project are on PMC, only PMC members have binding votes for releases, PMC should be monitoring all releases, and so on). But I got out of the business of trying to understand how things are supposed to work at Apache a couple of years ago :) daniel -#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#- http://www.savarese.org/ In distant lands, I hear the call of my home. # s a v a r e s e Yet my work is not done. My journey's just begun.-software research -- http://www.sleepandthetraveller.com/ # http://www.savarese.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Two community proposals
On Mon, 6 Mar 2006, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Henri Yandell writes: 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. I'm okay with both suggestions because it maps directly to how I thought things were supposed to work (i.e., all committers in a project are on PMC, only PMC members have binding votes for releases, PMC should be monitoring all releases, and so on). But I got out of the business of trying to understand how things are supposed to work at Apache a couple of years ago :) You understand it right. We've been using semantics for a few years to avoid sweeping changes. ie) PMC monitoring all releases = At least 3 PMC members voting for it, and a RESULT email to the PMC. Obeys the rules and the Jakarta spirit, though not the ASF spirit I suspect. I also suspect that I'll need to post this to every -dev list. Given that there is no Jakarta community, I doubt everyone listens to this list. I was expecting an explosion from POI at the least :) [due to their legal worries over commit rights]. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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]
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: [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: [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: [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: [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: [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: [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: [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: [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: [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]
