Re: [PROPOSAL] Committer access and responsibilities...
On Thu, 2002-05-30 at 01:49, Ted Husted wrote: If you accept a nomination to be a committer, and gain CVS access, then you can apply your own patches. Since most of use the products we patch, this is an important benefit to most contributors. If you happen to see a patch from another contributor that you think is useful, you can apply that too. But none of us are obligated to do anything we don't want to do. That will attract volunteers a great deal ;((. The least the project (and therefor also you as a committer), has an obligation to give a reasonable response to the effort taken. Clouding the mailinglist with reminders (what some projects actually specifically ask for), is actually not something I should invest my time in. Just a simple we don't have time for it now, it is on the todo list.. , would do in many cases. So if you don't want to take that effort : don't take up the responsibility of being a committer. So the obligation to do something with it, is of the project and if you are part of that you have an obligation. Mvgr, Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Case can be made that since putting something in CVS is putting something up for lazy majority vote (and I subscribe to that), this is not a good 'use case'. But what is wrong with a role for people that have the option to propose something for a lazy majority vote, and then no right/obligation to actually vote on that 'something' or anything else? I think with rights comes responsibility. Yeah, exactly. And what if there is someone who actually wants less responsibility and less rights than a committer, but still more than a contributor? It is all about granularity: less rights, less responsibility. Gee I'd like to dump my code here and not bother with the community Gee I've created this amazing forked version of your codebase (this amazing book about your project, ..., ...) and now got permission from my employer to contribute it back. This is quite a lot of stuff, you can find it at http://somewhere/ to look at. If you accept, do you want 20MB worth of patches or can you give me CVS access? What if the community would very much like you to provide that stuff, you're already committer in other apache projects, but have no time to support your submission for longer than, say, a month? Should you be committer for a month? etc etc etc. cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Yeah, exactly. And what if there is someone who actually wants less responsibility and less rights than a committer, but still more than a contributor? -1 It is all about granularity: less rights, less responsibility. Gee I'd like to dump my code here and not bother with the community Gee I've created this amazing forked version of your codebase (this amazing book about your project, ..., ...) and now got permission from my employer to contribute it back. This is quite a lot of stuff, you can find it at http://somewhere/ to look at. If you accept, do you want 20MB worth of patches or can you give me CVS access? What if the community would very much like you to provide that stuff, you're already committer in other apache projects, but have no time to support your submission for longer than, say, a month? Should you be committer for a month? Does the term white elephant mean anything to you? I don't think there is anything to forbid a community from temporarily granting CVS access. I would say such a gift should not be interpreted with the direct meaning of the word in German. Such things usually are wrought with problems and with this person who dumps a bunch of code into your repository and leaves, well generally it reduces the quality of your codebase and no one who IS part of the community knows the code. -Andy etc etc etc. cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote: Yeah, exactly. And what if there is someone who actually wants less responsibility and less rights than a committer, but still more than a contributor? -1 why? Does the term white elephant mean anything to you? thought that was a special kind of elephant... http://www.dictionary.com/search?q=white%20elephant ...does now. I don't think there is anything to forbid a community from temporarily granting CVS access. ;) Well, I think our guidelines forbid us. You cannot give someone CVS access without giving them all the committer rights and responsibilities as well. That's the point of the discussion, innit? I would say such a gift should not be interpreted with the direct meaning of the word in German. Such things usually are wrought with problems and with this person who dumps a bunch of code into your repository and leaves, well generally it reduces the quality of your codebase and no one who IS part of the community knows the code. This is of course, generalising, and we're leading away from the discussion here. I say we should evaluate role/right/responsibility granularity, you write an example line of thought of a potential candidate for a new role to illustrate you disagree, so I provide a counterexample. Not going anywhere; I'd rather see an answer to: Why is increased granularity in role/right/responsibility bad in general? and Why is defining a new role that is in between the currently defined roles of contributor and committer in terms of rights and responsibilities a bad thing? cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
From: Leo Simons [EMAIL PROTECTED] On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote: I don't think there is anything to forbid a community from temporarily granting CVS access. ;) Well, I think our guidelines forbid us. You cannot give someone CVS access without giving them all the committer rights and responsibilities as well. That's the point of the discussion, innit? Yes, it is. I regard CVS as the heart of our system. Would you make a well known surgeon operate your heart without knowing him first, and being sure he can assist you afterwards? If you do, usually it's for emergencies... like wanting some 20MB patch to be in CVS and not having time to do it. Personally, I would prefer not have the patch at all, if it means giving access to the CVS to someone you don't trust. And if you trust him, there is no time limit. Nothing prevents him from asking his account to be deleted anyway. If you invite someone in the boat with you, it's because you think that he'll be part of the group, and share roles and responsibilities; I don't think we need technical repairmen here. I may be wrong, but for me it's a matter of trust, personal trust. I have been contributing stuff to Cocoon since version 1.7, but never proposed as a comitter. Why? Because I wasn't ready for OS collaboration, and they didn't trust me. This made me stronger, and I learned a lot. Now you made me come in Avalon just on my word and good proposition, and this is something I will never forget. It has a very strong meaning for me. I would like that others have these possibilities, that have made me learn a lot. I'm afraid that having technitians would break up this system. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Committer access and responsibilities...
Despite all the arguments I still can NOT see why it should be more complicated than this (Sam + Jon definitions). Probably the system is already as good as it can get. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 5:59 PM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Committer access and responsibilities... ... A developer can suggest a change. A committer can make it happen. - Sam Ruby Anyone can suggest a change. A developer can submit a patch. A committer can make it happen. ;-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
thought that was a special kind of elephant... http://www.dictionary.com/search?q=white%20elephant ...does now. In some Asian cultures, a particularaly cruel way to blight someone you didn't like was to gift them a white elephant. They'd need to feed and take care of it because they were considered something sacred and rare -- but an elephant eats a lotand well outputs a lot as well. I don't think there is anything to forbid a community from temporarily granting CVS access. ;) Well, I think our guidelines forbid us. You cannot give someone CVS access without giving them all the committer rights and responsibilities as well. That's the point of the discussion, innit? Pragmatically I think if a community voted to temporarily grant access to its CVS repository, I'll bet it could be done. Not going anywhere; I'd rather see an answer to: Why is increased granularity in role/right/responsibility bad in general? 1. Because it is a cop out. 2. If this is about community and not code then we want participating members in the community 3. granularity is a clever way of putting it, but thats not what this is about 4. Code dumps are white elephants 5. Opening the floodgates to CVS is bad (for so many reasons), 6. If you trust them in the repository, you accept their code, then they should be part of the community, otherwise, you shouldn't accept either. and Why is defining a new role that is in between the currently defined roles of contributor and committer in terms of rights and responsibilities a bad thing? I've explained this sufficiently in this and other emails. I do not think defining a role for folks whose work is not CVS-based but just as relevant if its clearly defined. Overall I'm happy with the organization as it is and do not think it needs radical social engineering. -Andy cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Nicola Ken Barozzi wrote: From: Leo Simons [EMAIL PROTECTED] On Wed, 2002-05-29 at 14:04, Andrew C. Oliver wrote: I don't think there is anything to forbid a community from temporarily granting CVS access. ;) Well, I think our guidelines forbid us. You cannot give someone CVS access without giving them all the committer rights and responsibilities as well. That's the point of the discussion, innit? Yes, it is. I regard CVS as the heart of our system. to me the point that Pier was trying to get accross that I agreed with is that there is sometimes work that happens outside of CVS worthy of committership (and/or that should require committership) irrelevant of CVS access. Would you make a well known surgeon operate your heart without knowing him first, and being sure he can assist you afterwards? If you do, usually it's for emergencies... like wanting some 20MB patch to be in CVS and not having time to do it. Personally, I would prefer not have the patch at all, if it means giving access to the CVS to someone you don't trust. And if you trust him, there is no time limit. Nothing prevents him from asking his account to be deleted anyway. Agreed. If you invite someone in the boat with you, it's because you think that he'll be part of the group, and share roles and responsibilities; I don't think we need technical repairmen here. I may be wrong, but for me it's a matter of trust, personal trust. Agreed. I have been contributing stuff to Cocoon since version 1.7, but never proposed as a comitter. Why? Because I wasn't ready for OS collaboration, and they didn't trust me. This made me stronger, and I learned a lot. Now you made me come in Avalon just on my word and good proposition, and this is something I will never forget. It has a very strong meaning for me. I would like that others have these possibilities, that have made me learn a lot. I'm afraid that having technitians would break up this system. Well spoken! -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Leo Simons wrote: On Wed, 2002-05-29 at 15:50, Paulo Gaspar wrote: Despite all the arguments I still can NOT see why it should be more complicated than this (Sam + Jon definitions). there's been numerous examples mentioned in this thread. Also, the system already _is_ more complicated than the definitions below. A committer can also vote for the PMC. Someone who wants to do administration/documentation but should not be trusted with CVS should not be made a committer, etc etc etc. \ Now that I can get my fingers around. (not documentation as that does go in CVS). Someone who administrates all of the Mail servers, Bugzilla, etc etc. Should be a committer, but should not require CVS access. I propose the following solution. Next time that is needed propose them a committer, vote them in and then do not request CVS access for them. Root won't do it unless asked. I'll bet if you say give everything but CVS access to, root will serve the request! (Simple, elegant, practical...it just won't do!) Probably the system is already as good as it can get. I think the underlying thoughts and the spirit of the system (like what's written below, the concepts of meritocracy, do-ocracy, trust, etc) are about as good as it gets. Implementation can always use some work ;) - Leo Anyone can suggest a change. A developer can submit a patch. A committer can make it happen. ;-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Why is increased granularity in role/right/responsibility bad in general? 1. Because it is a cop out. http://www.dictionary.com/search?q=cop%20out (I'm learning today =) which one do you mean? /**/ To avoid fulfilling a commitment or responsibility; renege: copped out on my friends; copped out by ducking the issue. 2. If this is about community and not code then we want participating members in the community don't follow...you mean limited community participating should not be an option if you want right X? Yes. 3. granularity is a clever way of putting it, but thats not what this is about I think there's a close relationship. You could also talk about decoupling, as Pier coined it, leading to: Why is decoupling sets of rights/responsibilities from each other a bad thing? Note that doing so would lead to an increase in roles, ie a more granular system. Just my view of the world... No I think bestowing committership on people who have CVS-Like access (shell access is an equal amount of trust) is different from bestowing committership without voting rights/etc. 4. Code dumps are white elephants one does not automatically lead to another. Increased granularity (right/responsibility set decoupling) doesn't mean an increase in code dumps. That was your rationale for this. 5. Opening the floodgates to CVS is bad (for so many reasons), same as for 4. its still bad. 6. If you trust them in the repository, you accept their code, then they should be part of the community, yes. But there are various ways of participating in the community. You can accept their code and trust them in the repository, and they can be a member of the community, and still not be a committer. Well, not now, but the thought is to change that. That is a bad idea. This is about the specific case of creating a role that provides cvs access and no other rights, though. give me a use case other than code dumps. I see no compelling need for this. I've explained this sufficiently in this and other emails. except I still don't get it =) I don't get why you'd want to effect this change. :-) I do not think defining a role for folks whose work is not CVS-based but just as relevant if its clearly defined. you ment to end with is stupid/bad or something, right? On that the two of us agree, then? (now for the rest of the world...) sorry I meant to say that non CVS-based committers should be recognized. (shell access is just as big of a trust thing as CVS access if not bigger) Overall I'm happy with the organization as it is and do not think it needs radical social engineering. of course. But maintainance is cool. only where needed. -Andy cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
on 5/29/02 7:23 AM, Andrew C. Oliver [EMAIL PROTECTED] wrote: to me the point that Pier was trying to get accross that I agreed with is that there is sometimes work that happens outside of CVS worthy of committership (and/or that should require committership) irrelevant of CVS access. Yea, like that code that will auto-format your code on checkin that you threatened to write a month or so ago... ;-) -jon (still waiting) stevens -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Jon Scott Stevens wrote: on 5/29/02 7:23 AM, Andrew C. Oliver [EMAIL PROTECTED] wrote: to me the point that Pier was trying to get accross that I agreed with is that there is sometimes work that happens outside of CVS worthy of committership (and/or that should require committership) irrelevant of CVS access. Yea, like that code that will auto-format your code on checkin that you threatened to write a month or so ago... ;-) -jon (still waiting) stevens Not that it had anything to do with anything but I got shot down by the POI community. They don't want their code reformatted.Check the archives. I began the proposal with Any discussion regarding bracket placement automatically kills this proposal and it shall be hereby recended... -Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
on 5/29/02 1:47 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: I got shot down by the POI community. Sounds like a common thread, eh? ;-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Ted Husted wrote: I believe the fundamental principal behind our system is Them that does the work makes the decisions. +1 I believe a secondary principal behind our system is Thanks for volunteering. +1 - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
on 5/29/02 4:53 PM, Sam Ruby [EMAIL PROTECTED] wrote: Ted Husted wrote: I believe the fundamental principal behind our system is Them that does the work makes the decisions. +1 I believe a secondary principal behind our system is Thanks for volunteering. +1 - Sam Ruby I can't agree more. Babble all day long about random crap, but when it comes down to it, it is the people who actually do the work that make the decisions. I have proven this time and time again. Strong case in pointthe jakarta.apache.org and www.apache.org websites are built with Anakianot that XSLT crap. ;-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Jon Scott Stevens wrote: on 5/29/02 1:47 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: I got shot down by the POI community. Sounds like a common thread, eh? Not sure what you mean. How's the bar doing? -Andy ;-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Since this is a volunteer organization, and we all have other pressing responsibilities, it is important that we do not encourage any systemic bottlenecks. I wrote: user: no rights, no responsibilities developer: right to get quoted as author for authored pieces, no responsibility committer: right to vote as per voting guidelines, responsibility to sign and submit Contributor License Agreement pmc member: right and obligation to set overall project direction this is not quite reflective of our current situation. The term developer can sometimes be misleading (contributor would be better, perhaps), while committer perhaps should include some added guidelines wrt responsibilities. You might call the fact that these definitions are somewhat out of whack a systemic bottleneck. Since committing is voting, what I think what some people want is a non-vetoing Committer. I think 'some people' don't see/don't agree to the committing is voting, and then what they want is a Developer-with-CVS-access, which is more or less what they said. Committing is voting is not reflected in our guidelines (at least I couldn't find such a notion). Someone to do the work without sharing in the responsibility. sounds like what we call developer in our guidelines ;) Which is to say, we can reject what they do, but they can't reject what we do. Personally, I would find that type of master/slave relationship difficult to maintain in a volunteer organization like this. If you are working hard enough to need commit rights, you are working hard enough to have veto rights. What if someone wants/needs commit rights but doesn't want the veto rights (and responsibilities)? The right to vote also means an obligation to vote/abstain. The implication of your statement is if you are given cvs access, you should also take on the responsibility of voting. cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Leo Simons wrote: Since committing is voting, what I think what some people want is a non-vetoing Committer. I think 'some people' don't see/don't agree to the committing is voting, and then what they want is a Developer-with-CVS-access, which is more or less what they said. Committing is voting is not reflected in our guidelines (at least I couldn't find such a notion). In projects like http://httpd.apache.org/dev/guidelines.html, any impleementation of an idea (as opposed to a simple patch) must be review-then-comment. In most Jakarta subprojects, the norm is lazy consensus as defined in http://jakarta.apache.org/site/decisions.html. So, think of a commit as the first (any typically only) +1 most changes get. Someone to do the work without sharing in the responsibility. sounds like what we call developer in our guidelines ;) A developer can suggest a change. A committer can make it happen. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
on 5/28/02 12:12 AM, Sam Ruby [EMAIL PROTECTED] wrote: Leo Simons wrote: Since committing is voting, what I think what some people want is a non-vetoing Committer. I think 'some people' don't see/don't agree to the committing is voting, and then what they want is a Developer-with-CVS-access, which is more or less what they said. Committing is voting is not reflected in our guidelines (at least I couldn't find such a notion). In projects like http://httpd.apache.org/dev/guidelines.html, any impleementation of an idea (as opposed to a simple patch) must be review-then-comment. In most Jakarta subprojects, the norm is lazy consensus as defined in http://jakarta.apache.org/site/decisions.html. So, think of a commit as the first (any typically only) +1 most changes get. Someone to do the work without sharing in the responsibility. sounds like what we call developer in our guidelines ;) A developer can suggest a change. A committer can make it happen. - Sam Ruby Anyone can suggest a change. A developer can submit a patch. A committer can make it happen. ;-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Tue, 2002-05-28 at 17:36, Leo Simons wrote: On Tue, 2002-05-28 at 14:20, Andrew C. Oliver wrote: I totally disagree with everything you just said. Uhm, I think you disagree with the idea we should have 'developers/contributors' with CVS access who are not committers. I'm not sure whether I support that idea yet. You also disagree with the other stuff I said? I do NOT think developers should be granted CVS access without voting rights. Thats a cop out. That says Gee we trust you in CVS but don't want to give you the rights to control your work or give you any ownership in what you do. If they are frequent enough committers to require CVS access...then they deserve the rights there under. Missing the point I made that there might be people out there that want some of the rights that come with committer status, not caring about having all of them, while not wanting all of the duties that come with committer status. I want a million dollars with no responsibilities such as paying taxes or any of that stuff. With rights come responsibilities, such is life. Heck, I'll probably submit more than a few patches to centipede in the future; people will probably get tired of applying them and they might ask me to become a committer, to which I will say no thanks as I feel I have have no time to make that commitment. It'll still be easier for both the committers and me if I still get CVS access. Centipede is not a Jakarta project, and if the voting rules for centipede are documented, I missed the link. I think for the moment its either common law or understood because nearly everyone there is a committer on some Apache project somewhere. I'm not saying we should allow it, just that there's two sides to the story. I'd in fact -1 the idea of giving you CVS access without agreeing to be a committer. Krysalis (from what I can tell) actually has a slightly different type of committership. One is a committer to all projects (meaning I get to vote on Wings and Centipede both). I think I may be (there) an excellent example of the type of committer that Pier talks about. I've actually committed 0 code to Wings or Centipede. All of my work has been in setup, publicising, cross OS-testing, and well lots of little things that aren't code but that well the project might not be where it is today had I not done them. Case can be made that since putting something in CVS is putting something up for lazy majority vote (and I subscribe to that), this is not a good 'use case'. But what is wrong with a role for people that have the option to propose something for a lazy majority vote, and then no right/obligation to actually vote on that 'something' or anything else? I think with rights comes responsibility. Gee I'd like to dump my code here and not bother with the community I want a million dollars without bothering with earning it or the taxes or jailtime or whatever... -Andy g'night, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Hi, I would love to be able to give people partiial access to projects and I would also love to expire accounts if they are dormant or the person goes MIA. For instance the first one would be especially useful in projects like ant, excalibur and commons. Many times in ant the committers have wanted to give a person access to a certain subtree in CVS because they contributed it and would be able to maintain it. ie Originally the Perforce tasks in Ant were largely contributed by a single individual and it would have been great if that person coul ddirectly maintain them. However given that every new committer needs a new account on the boxen we never moved forward on it. When more appropriate infrastructure is put in place (Subversion - rah rah rah! Subversion - rah rah rah!) I think it would definetly be a good idea to do that. However that may put too big a burden on the system admins. When the new infrastructure is in place (think subversion, eyebrowse, scarab, + some mailing list management software + some product release software) it would be very beneficial to push the administration down onto project leads and away from sys admins (who are prolly overloaded anyways). No one besides a select few would even need accounts. Of course this needs a lot of volunteers to get started but until then I am not sure it would be possible to please everyone. However when thats in place all projects effectively manage themselves as they see fit. On Sat, 25 May 2002 09:06, Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So the major topic of discussion is that I perceive a substantial difference between being able to commit code to a CVS repository, and being a committer committer, with all dues and responsibilities that this role concerns... For example sometimes someone might want to have commit access just because he is working for a company that deals with a particular project in Apache (we've seen this happening several times with some projects such as Xerces and Tomcat), but he really doesn't care about the whole fuzz of Apache and stuff, and once the employment contract ends, the relationship with Apache terminates as well (I don't need to enumerate all those examples along those lines). One other example, if we didn't have Henri building RPMs for basically all Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, don't you think that he would deserve committer status even if he's not tied to any particular codebase? We had this problem in the current election of the members, Sally Khudairi: Sally doesn't code, but she was involved with the ASF since before it was even created as a press organizer. Does she deserve to be a member of the foundation? Even if she doesn't code? Yes she does, IMO (and she was elected and nominated a member today)... So, IMO, there's a great difference between being a coder, and being a member of the Jakarta community, at least in my opinion. There might be coders who are not involved with the community, and there might be non-coders who are much involved with it, want to participate, are active and deserve to be committers... Our current structure doesn't allow that to happen, both things. If you need to write code in a particular source-base, and you need CVS access, you are automagically made a committer, even if you don't care about much else, and if you're very much involved with the overall project, but not tied to ANY whatsoever codebase, and really, don't want / can't do it. So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). I believe this makes sense, more sense than what we have now, also because we've seen that happening in the ASF for the
RE: [PROPOSAL] Committer access and responsibilities...
Hi Andrew, -Mensaje original- De: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Enviado el: sábado 25 de mayo de 2002 18:39 Para: Jakarta General List Asunto: Re: [PROPOSAL] Committer access and responsibilities... From my understanding, in most European parliamentary democracies, generally you vote for more issue-oriented parties. Even if you loose you take a certain number of seats. So it makes sense to vote regardless of whether its going to be a landslide. In most European countries, voting is as irrelevant as it's in the States: http://www.billionairesforbushorgore.com/ In Spain we've seen socialists undercutting social benefits and privatizing public companies; and right-wing parties supporting abortion and promoting public function. (Not a bad thing, necessarily, just a sign of the times). I'm sure you can think of similar examples in your own countries. The true strength of the Apache community is, IMHO, not in its democratic values, but in the spirit of cooperation. Only when this fails, does the result suck (Apache Axis comes to mind). Un saludo, Alex.
Re: [PROPOSAL] Committer access and responsibilities...
+ some mailing list management software + some product release software) it would be very beneficial to push the administration down onto project leads So we'll also have 'project leads' ? And some people who write and maintain code, but have different rights ? we have, in practice, in quite a few of the subprojects. The in practice part in that sentence explains the quotes around leads. We have a nice theoretical meritocracy model defining several roles and responsibilities. That's just fine. The current model defines user, developer, committer and pmc member. In real life, there's more roles, overlapping roles, more specific roles, less specific roles. Examples: with Avalon, Peter and Berin handle most of our releases; they assume the role of release manager. Jeff Turner's been working on the build process; he had the cap of build process manager, now passed over to Nicola Ken, all informally. Fortunately, this is all okay and no-one complains. Like Ted said, we're pragmatic about it. Thing is, formal roles and responsibilities currently are (as per http://jakarta.apache.org/site/roles.html): user: no rights, no responsibilities developer: right to get quoted as author for authored pieces, no responsibility committer: right to vote as per voting guidelines, responsibility to sign and submit Contributor License Agreement pmc member: right and obligation to set overall project direction when these no longer reflect the ad hoc pragmatic roles defined within subprojects, or when they make using these pragmatic roles difficult, we should think about changing these definitions, roles and responsibilities. Fact of the matter is, the model is not perfect, and not everyone in our community fits into these categories very well. Saying that everyone who submits a patch is a developer is a bit of a strange definition, as you don't really develop documentation, etc etc etc. Pier brings this up, perhaps in a somewhat clumsy way, but with a valid point and valid arguments: voila, heated discussion and comments on a personal note. if it ain't broken, don't fix it leads to things like windows. We'd still be forced to work with AWT and JSP. - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
I think the real point is that while, given the chance, some people may prefer to do one thing or another, as Committers we all can potentially do anything that needs to be done whenever we have time to do it. Since this is a volunteer organization, and we all have other pressing responsibilities, it is important that we do not encourage any systemic bottlenecks. If the Committer who likes to do the releases can't, someone else can just step up to bat without any hoopla. A committer is a committer .. from each according to their abilities, to each according to their needs. Regardless of what we choose to do from time to time, the codebase is our joint responsiblity. And when we drift away, someone else will step into our shoes. When we are gone, another committer may elect to do what we used to do, or a new contributor may fill the void and then be nominated as the product's newest Committer. The real problem I would have with non-voting Committers is that comitting is an important way of how we vote. Because we are all responsible for the entire codebase, jointly and severally, we don't have to vote on every little thing. We can vote through our commits -- unless and until another Committer points out an error in our judgment. Since committing is voting, what I think what some people want is a non-vetoing Committer. Someone to do the work without sharing in the responsibility. Which is to say, we can reject what they do, but they can't reject what we do. Personally, I would find that type of master/slave relationship difficult to maintain in a volunteer organization like this. If you are working hard enough to need commit rights, you are working hard enough to have veto rights. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Leo Simons wrote: we have, in practice, in quite a few of the subprojects. The in practice part in that sentence explains the quotes around leads. We have a nice theoretical meritocracy model defining several roles and responsibilities. That's just fine. The current model defines user, developer, committer and pmc member. In real life, there's more roles, overlapping roles, more specific roles, less specific roles. Examples: with Avalon, Peter and Berin handle most of our releases; they assume the role of release manager. Jeff Turner's been working on the build process; he had the cap of build process manager, now passed over to Nicola Ken, all informally. Fortunately, this is all okay and no-one complains. Like Ted said, we're pragmatic about it. Thing is, formal roles and responsibilities currently are (as per http://jakarta.apache.org/site/roles.html): user: no rights, no responsibilities developer: right to get quoted as author for authored pieces, no responsibility committer: right to vote as per voting guidelines, responsibility to sign and submit Contributor License Agreement pmc member: right and obligation to set overall project direction when these no longer reflect the ad hoc pragmatic roles defined within subprojects, or when they make using these pragmatic roles difficult, we should think about changing these definitions, roles and responsibilities. Fact of the matter is, the model is not perfect, and not everyone in our community fits into these categories very well. Saying that everyone who submits a patch is a developer is a bit of a strange definition, as you don't really develop documentation, etc etc etc. Pier brings this up, perhaps in a somewhat clumsy way, but with a valid point and valid arguments: voila, heated discussion and comments on a personal note. if it ain't broken, don't fix it leads to things like windows. We'd still be forced to work with AWT and JSP. - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Ted Husted wrote: Since committing is voting... +1 - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Tue, 28 May 2002 03:12, [EMAIL PROTECTED] wrote: On Sun, 26 May 2002, Peter Donald wrote: + some mailing list management software + some product release software) it would be very beneficial to push the administration down onto project leads So we'll also have 'project leads' ? we already do in practice. Some projects more so than others. As been stated before - Apache is a meritocracy, the more you contribute, the more responsibility and power you receive. -- Cheers, Peter Donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Committer access and responsibilities...
+0 I like this, I think it is needed, as it should help to extend the experience and knowledge of the community by acknowledging the services of non-coders. I believe, though, that as sub-projects grow we will eventually need to address the issue of scope, but in the meantime this would be an improvement. But Pier, it doesn't address your original problem though, does it? Which was about the bar height, or how to encourage contributors, and increase the number of contributors without diluting, and clogging up, the community and decision making processes. d. - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). I believe this makes sense, more sense than what we have now, also because we've seen that happening in the ASF for the very first time with a non-coding member. Comments please? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Committer access and responsibilities...
But Pier, it doesn't address your original problem though, does it? Which was about the bar height, or how to encourage contributors, and increase the number of contributors without diluting, and clogging up, the community and decision making processes. Total and complete agreement. Well said Sir. -Andy d. - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). I believe this makes sense, more sense than what we have now, also because we've seen that happening in the ASF for the very first time with a non-coding member. Comments please? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Those who do the work of creating a Jakarta product are entitled to make the decisions regarding that product. A successful product is more than code, it also requires documentation and support and easy-to-use distributions. Whether a patch is to the code or the documentation isn't relevant. A patch is a patch, a contribution is a contribution, and anyone who makes sustained contributions to a product is elligible to become a committer. A change to the codebase can affect everyone, including them that don't code but simply document. They should have as much to say about the codebase as everyone else. The real point behind meritocracy, I believe, is that we are all equal and there is no formal hierarchy. It's also a big part of what makes Jakarta both fun and different from our regular jobs. We have a simple and effective system here that's been proven to work. I don't believe that the formal system is broken or needs to be refactored. -1 on there being shades of gray between contributors and committers. A contributor is anyone who has submitted code, documentation or any other deliverable that has been made part of the product. Committers do the work of creating the product by posting contributions to the CVS or other secure area. +1 on non-coders or specialists being voted as committers when the circumstances warrant. There is nothing to prevent this now nor should there ever be. If its OK with the other committers to a product, there's no reason for the rest of us to care. If it's not OK with the other committers, then it is not the system that's broken, but the committers -- and no amount of tinkering is going to fix that. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So the major topic of discussion is that I perceive a substantial difference between being able to commit code to a CVS repository, and being a committer committer, with all dues and responsibilities that this role concerns... For example sometimes someone might want to have commit access just because he is working for a company that deals with a particular project in Apache (we've seen this happening several times with some projects such as Xerces and Tomcat), but he really doesn't care about the whole fuzz of Apache and stuff, and once the employment contract ends, the relationship with Apache terminates as well (I don't need to enumerate all those examples along those lines). One other example, if we didn't have Henri building RPMs for basically all Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, don't you think that he would deserve committer status even if he's not tied to any particular codebase? We had this problem in the current election of the members, Sally Khudairi: Sally doesn't code, but she was involved with the ASF since before it was even created as a press organizer. Does she deserve to be a member of the foundation? Even if she doesn't code? Yes she does, IMO (and she was elected and nominated a member today)... So, IMO, there's a great difference between being a coder, and being a member of the Jakarta community, at least in my opinion. There might be coders who are not involved with the community, and there might be non-coders who are much involved with it, want to participate, are active and deserve to be committers... Our current structure doesn't allow that to happen, both things. If you need to write code in a particular source-base, and you need CVS access, you are automagically made a committer, even if you don't care about much else, and if you're very much involved with the overall project, but not tied to ANY whatsoever codebase, and really, don't want / can't do it. So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all the
Re: [PROPOSAL] Committer access and responsibilities...
Well said. I subscribe to this. We should remember that people that contribute so much should be proposed as committers, regardless to the code submitted, as is done AFAIK in POI, Struts, Cocoon, Forrest, Avalon, and the Krysalis projects (that refer to Apache guidelines). -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Sunday, May 26, 2002 6:59 PM Subject: Re: [PROPOSAL] Committer access and responsibilities... Those who do the work of creating a Jakarta product are entitled to make the decisions regarding that product. A successful product is more than code, it also requires documentation and support and easy-to-use distributions. Whether a patch is to the code or the documentation isn't relevant. A patch is a patch, a contribution is a contribution, and anyone who makes sustained contributions to a product is elligible to become a committer. A change to the codebase can affect everyone, including them that don't code but simply document. They should have as much to say about the codebase as everyone else. The real point behind meritocracy, I believe, is that we are all equal and there is no formal hierarchy. It's also a big part of what makes Jakarta both fun and different from our regular jobs. We have a simple and effective system here that's been proven to work. I don't believe that the formal system is broken or needs to be refactored. -1 on there being shades of gray between contributors and committers. A contributor is anyone who has submitted code, documentation or any other deliverable that has been made part of the product. Committers do the work of creating the product by posting contributions to the CVS or other secure area. +1 on non-coders or specialists being voted as committers when the circumstances warrant. There is nothing to prevent this now nor should there ever be. If its OK with the other committers to a product, there's no reason for the rest of us to care. If it's not OK with the other committers, then it is not the system that's broken, but the committers -- and no amount of tinkering is going to fix that. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So the major topic of discussion is that I perceive a substantial difference between being able to commit code to a CVS repository, and being a committer committer, with all dues and responsibilities that this role concerns... For example sometimes someone might want to have commit access just because he is working for a company that deals with a particular project in Apache (we've seen this happening several times with some projects such as Xerces and Tomcat), but he really doesn't care about the whole fuzz of Apache and stuff, and once the employment contract ends, the relationship with Apache terminates as well (I don't need to enumerate all those examples along those lines). One other example, if we didn't have Henri building RPMs for basically all Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, don't you think that he would deserve committer status even if he's not tied to any particular codebase? We had this problem in the current election of the members, Sally Khudairi: Sally doesn't code, but she was involved with the ASF since before it was even created as a press organizer. Does she deserve to be a member of the foundation? Even if she doesn't code? Yes she does, IMO (and she was elected and nominated a member today)... So, IMO, there's a great difference between being a coder, and being a member of the Jakarta community, at least in my opinion. There might be coders who are not involved with the community, and there might be non-coders who are much involved with it, want to participate, are active and deserve to be committers... Our current structure doesn't allow that to happen, both things. If you need to write code in a particular source-base, and you need CVS access, you are automagically made a committer, even if you don't care about much else, and if you're very much involved with the overall project, but not tied to ANY whatsoever codebase, and really, don't want / can't do it. So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor
Re: [PROPOSAL] Committer access and responsibilities...
- Original Message - From: [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Saturday, May 25, 2002 9:17 PM Subject: RE: [PROPOSAL] Committer access and responsibilities... On Sun, 26 May 2002, Ignacio J. Ortega wrote: but all i can say from the history i know, that you are simply suffering some kind of father syndrome, like those fathers that, when his children Stop reading Freud :-) ! Before Nacho kicked in, I was going for Jungian myself. :) We need to add as commiters not only a lawyer, but also a shrink now. +1 for the shrink. That way I might be able to get through my inbox in finite time. ;-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sat, 25 May 2002, Pier Fumagalli wrote: If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Hola, you tend to forget a part I'm stressing out quite hardly... It's not only rights... It's also dues, right? Yes, the 'due' to spend weekends writing code or answering emails or reading flame wars. Give me a break with the big 'due' to vote or have a say over how the project you're involved with. And in fact, Costin, the big opposition you're going to get from me, will always be on the fact that you are totally and utterly irresponsible towards this community and the ASF... It's years that you're been told that, not only from me, but from an extended number of people (do we want to get back to the Tomcat 3.x/4.x flamewar? Read those comments)... Anyway, nice talking to you (not). Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Tim Vernum [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. But it's not just about exercising rights, it's also about granting rights. At the moment, you cannot grant someone one right (commit access) without also granting them additional rights (voting etc). Some people (myself included) would claim that the condition of entry for those rights, are not equal. Thanks, it seems that few people understood what I'm trying to do: freeing the community from being tied down to a particular CVS repository and restructuring it, for most of the otehrs I'm just someone who wants to lock up this community and strip it of its freedom... Bah :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, May 25, 2002 at 02:04:24PM +0100, Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sat, 25 May 2002, Pier Fumagalli wrote: If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Hola, you tend to forget a part I'm stressing out quite hardly... It's not only rights... It's also dues, right? Yes, the 'due' to spend weekends writing code or answering emails or reading flame wars. Give me a break with the big 'due' to vote or have a say over how the project you're involved with. And in fact, Costin, the big opposition you're going to get from me, will always be on the fact that you are totally and utterly irresponsible towards this community and the ASF... It's years that you're been told that, not only from me, but from an extended number of people (do we want to get back to the Tomcat 3.x/4.x flamewar? Read those comments)... Aren't we all happy that 3.3.x exists, and is better than 3.2.x? Aren't we all happy that we have a choice to 4.x? Aren't we all happy that Jon was 'mislead' into not -1'ing Struts (one of Jakarta's biggest successes)? Perhaps people should be less certain they know what is best for the community :P Anyway, nice talking to you (not). .. and thankful that people like Costin persevere in spite of rather vicious abuse. --Jeff (a happy 3.3.x and Struts user, whose sense of justice temporarily outweighs an aversion to general@ flamewars) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Even though I am not a committer / member (I try to contribute code however), I just needed to express my opinion ;). I am a +1 on Piers proposal. Especially the membership possibility for people who are not coding can be very constructive for this community! Designers, politicians, copywriters, lawyers, nannies, cleaning lady, sys admins, people with great ideas (the thinkers) etc,etc.. A community is more then just programming, although it is our core business here. Others can give us a look at things we didn't have before and make life a little bit easier for us code monkeys (or as I call myself in dutch tiep miep) Just my 2 euro cents ;) Mvgr, Martin PS this is not a pro Pier (or whoever) and con Costin (or whoever) thing. So let's keep it that way and ignore the comments about that to each other. If you cannot mail something independend of the past, besidees the current subject, don't mail it or mail it in private, or better be the wisest to ignore it. value teacher mode on I am not here to teach values or something like that (you are not waiting for that probably), but I am going to try anyway : The past is something that happened and is not now, you cannot blame people for what has taken place then, because it is not taking place now (with now I mean this Nanosecond even less). Life becomes so much easier if you obtain this view! No barriers to look back on, just plain free, non prejudiced communications. Wow we live in a great world! Forgive me my Martin logic, you will get used to it.. ;)) /value teacher mode off On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Martin van den Bemt [EMAIL PROTECTED] wrote: Designers, politicians, copywriters, lawyers, nannies, cleaning lady, sys admins, people with great ideas (the thinkers) etc,etc.. A community is more then just programming, although it is our core business here. Others can give us a look at things we didn't have before and make life a little bit easier for us code monkeys (or as I call myself in dutch tiep miep) _THIS_ is freedom. It doesn't look like a vicious abuse... Thank you Martin... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote: Even though I am not a committer / member (I try to contribute code however), I just needed to express my opinion ;). I am a +1 on Piers proposal. Especially the membership possibility for people who are not coding can be very constructive for this community! Designers, politicians, copywriters, lawyers, nannies, cleaning lady, sys admins, people with great ideas (the thinkers) etc,etc.. A community is more then just programming, although it is our core business here. Others can give us a look at things we didn't have before and make life a little bit easier for us code monkeys (or as I call myself in dutch tiep miep) I see lots of ideas floating around. Just few get implemented. -Andy Just my 2 euro cents ;) Mvgr, Martin PS this is not a pro Pier (or whoever) and con Costin (or whoever) thing. So let's keep it that way and ignore the comments about that to each other. If you cannot mail something independend of the past, besidees the current subject, don't mail it or mail it in private, or better be the wisest to ignore it. value teacher mode on I am not here to teach values or something like that (you are not waiting for that probably), but I am going to try anyway : The past is something that happened and is not now, you cannot blame people for what has taken place then, because it is not taking place now (with now I mean this Nanosecond even less). Life becomes so much easier if you obtain this view! No barriers to look back on, just plain free, non prejudiced communications. Wow we live in a great world! Forgive me my Martin logic, you will get used to it.. ;)) /value teacher mode off On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 2002-05-25 at 09:13, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. My projects haven't come to a grinding halt. Only on general @ jakarta is the sky always falling and Apache coming to an end. I prefer the status quo. Nothing you've said has convinced me that (it could be that I don't know who those people are anyhow) there is a compelling reason to change it. There are other things I see as more pressing than the need for more chiefs. -Andy Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Andy, With this attitude nothing gets ever implemented I guess. In this case Pier can hardly say : I am going to implement this and all of you comply! So he can implement whatever he wants, as long as it it still veto'd its no use investing spare time in. I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but to no avail, although some were complaining about lack of time. This new proposal will leave this kind of involvement at least open. Mvgr, Martin On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote: On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote: Even though I am not a committer / member (I try to contribute code however), I just needed to express my opinion ;). I am a +1 on Piers proposal. Especially the membership possibility for people who are not coding can be very constructive for this community! Designers, politicians, copywriters, lawyers, nannies, cleaning lady, sys admins, people with great ideas (the thinkers) etc,etc.. A community is more then just programming, although it is our core business here. Others can give us a look at things we didn't have before and make life a little bit easier for us code monkeys (or as I call myself in dutch tiep miep) I see lots of ideas floating around. Just few get implemented. -Andy Just my 2 euro cents ;) Mvgr, Martin PS this is not a pro Pier (or whoever) and con Costin (or whoever) thing. So let's keep it that way and ignore the comments about that to each other. If you cannot mail something independend of the past, besidees the current subject, don't mail it or mail it in private, or better be the wisest to ignore it. value teacher mode on I am not here to teach values or something like that (you are not waiting for that probably), but I am going to try anyway : The past is something that happened and is not now, you cannot blame people for what has taken place then, because it is not taking place now (with now I mean this Nanosecond even less). Life becomes so much easier if you obtain this view! No barriers to look back on, just plain free, non prejudiced communications. Wow we live in a great world! Forgive me my Martin logic, you will get used to it.. ;)) /value teacher mode off On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
I fail to see the connection between what I said and what you stated. I offered myself as installer of Scarab and it was accepted. I'll be implementing that shortly. (Step 1. Drive Server to chapel hill, Step 2. Install Scarab on it for practice, Step 3. install here) -Andy On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote: Andy, With this attitude nothing gets ever implemented I guess. In this case Pier can hardly say : I am going to implement this and all of you comply! So he can implement whatever he wants, as long as it it still veto'd its no use investing spare time in. I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but to no avail, although some were complaining about lack of time. This new proposal will leave this kind of involvement at least open. Mvgr, Martin On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote: On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote: Even though I am not a committer / member (I try to contribute code however), I just needed to express my opinion ;). I am a +1 on Piers proposal. Especially the membership possibility for people who are not coding can be very constructive for this community! Designers, politicians, copywriters, lawyers, nannies, cleaning lady, sys admins, people with great ideas (the thinkers) etc,etc.. A community is more then just programming, although it is our core business here. Others can give us a look at things we didn't have before and make life a little bit easier for us code monkeys (or as I call myself in dutch tiep miep) I see lots of ideas floating around. Just few get implemented. -Andy Just my 2 euro cents ;) Mvgr, Martin PS this is not a pro Pier (or whoever) and con Costin (or whoever) thing. So let's keep it that way and ignore the comments about that to each other. If you cannot mail something independend of the past, besidees the current subject, don't mail it or mail it in private, or better be the wisest to ignore it. value teacher mode on I am not here to teach values or something like that (you are not waiting for that probably), but I am going to try anyway : The past is something that happened and is not now, you cannot blame people for what has taken place then, because it is not taking place now (with now I mean this Nanosecond even less). Life becomes so much easier if you obtain this view! No barriers to look back on, just plain free, non prejudiced communications. Wow we live in a great world! Forgive me my Martin logic, you will get used to it.. ;)) /value teacher mode off On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 2002-05-25 at 17:16, Andrew C. Oliver wrote: I fail to see the connection between what I said and what you stated. Then I fail to see your connection with my story too.. I'll Give it try anyway : If no one cares or just one person cares and needs to vote of all to get things implemented or changed and doesn't get that vote, it will not get implemented, or even tried. I think that is normal behaviour here, so that is why I guess a lot of idea's never get implemented anyway, because you guys -1 it.. I offered myself as installer of Scarab and it was accepted. Guess you are a committer on jakarta? I am not. Is that the difference? This is exactly the reason why I said +1.. If you don't mind me asking out of interest : which project ? (else I have to dig into the avail file to see where you have commit access ;)) I'll be implementing that shortly. (Step 1. Drive Server to chapel hill, Step 2. Install Scarab on it for practice, Step 3. install here) It's broken now indeed ;) On the turbine list they are still saying that I have to use that to get bugs... Mvgr, Martin -Andy On Sat, 2002-05-25 at 11:05, Martin van den Bemt wrote: Andy, With this attitude nothing gets ever implemented I guess. In this case Pier can hardly say : I am going to implement this and all of you comply! So he can implement whatever he wants, as long as it it still veto'd its no use investing spare time in. I offered myself 2 times to jakarta as a sysadmin/co-list moderator, but to no avail, although some were complaining about lack of time. This new proposal will leave this kind of involvement at least open. Mvgr, Martin On Sat, 2002-05-25 at 16:49, Andrew C. Oliver wrote: On Sat, 2002-05-25 at 10:44, Martin van den Bemt wrote: Even though I am not a committer / member (I try to contribute code however), I just needed to express my opinion ;). I am a +1 on Piers proposal. Especially the membership possibility for people who are not coding can be very constructive for this community! Designers, politicians, copywriters, lawyers, nannies, cleaning lady, sys admins, people with great ideas (the thinkers) etc,etc.. A community is more then just programming, although it is our core business here. Others can give us a look at things we didn't have before and make life a little bit easier for us code monkeys (or as I call myself in dutch tiep miep) I see lots of ideas floating around. Just few get implemented. -Andy Just my 2 euro cents ;) Mvgr, Martin PS this is not a pro Pier (or whoever) and con Costin (or whoever) thing. So let's keep it that way and ignore the comments about that to each other. If you cannot mail something independend of the past, besidees the current subject, don't mail it or mail it in private, or better be the wisest to ignore it. value teacher mode on I am not here to teach values or something like that (you are not waiting for that probably), but I am going to try anyway : The past is something that happened and is not now, you cannot blame people for what has taken place then, because it is not taking place now (with now I mean this Nanosecond even less). Life becomes so much easier if you obtain this view! No barriers to look back on, just plain free, non prejudiced communications. Wow we live in a great world! Forgive me my Martin logic, you will get used to it.. ;)) /value teacher mode off On Sat, 2002-05-25 at 15:13, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Andrew C. Oliver [EMAIL PROTECTED] wrote: I fail to see the connection between what I said and what you stated. I offered myself as installer of Scarab and it was accepted. I'll be implementing that shortly. (Step 1. Drive Server to chapel hill, Step 2. Install Scarab on it for practice, Step 3. install here) Good. If you weren't a committer for POI, and you did that for the past 2 years, wouldn't you like to have a some sort of recognition by this community? Wouldn't you like to be able to elect the PMC? To decide what projects you'll have to deal with in your installation of the bug tracking system? I believe you would. Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
My projects haven't come to a grinding halt. Only on general @ jakarta But this isn't about your projects, it is about the community, and the community is more important than the code. Do you even know why you are here? -Andy -- jt (who is afraid Pier will do a mailing list search on him and realize how little value he brings to the community =) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
The converse: You all can vote all day long on what I'm to do, but what are you going to do when my dissenting vote is cast by me not actually doing it? Voting has NOTHING to do with what work gets done. Thats the POWER of those who do. We are talking about this proposal am I right not about a project proposal? So if there is a veto, you can do whatever you want, but you are doing it for nobody. Unless you want to push the proposal in, when the opportunity is there. I offered myself as installer of Scarab and it was accepted. Guess you are a committer on jakarta? I am not. Is that the difference? This is exactly the reason why I said +1.. If you contribute work, you'll become a committer, its as simple as that. I propose people committers because I can't keep up with their patches and get my own work done. (After I make sure they will fit into the community and they know how to use CVS). I would like to say I really value the opinions of everyone, but I don't. I value the opinions of those who are going to contribute something tangible to the project (even if its just critique of the documentation, bug reports, test files, etc). Don't think we are discussing the same thing here.. I refered to my offer of being a sysadmin/maillist moderator. Becoming a committer of any project isn't involved in that. Probably because you have to be committer to do such a thing, getting involved the community is pretty difficult. If +1 = Andy Do then thats a big -1 from me. If +1 = Yes and I'll do or help do then great! To let non-coders be committers cheapens the meaning. Agreed ont hat, but I guess you missed to point Pier made.. Pier wasn't suggesting that non-coders can be committers, just that they can be members. Its just a bunch of folks registering their opinion on what I should do. Yeah, the difference between that and toilette paper is that toilette paper is useful. You are all (seen this reference a couple of times now) thinking of members that take up jakarta management issues and that they become leaders.. I was just referring to people who can make life easier for the coders. If I was jakarta's sysadmin, and someones says we want to switch to scarab, I must be able to say -1 (when supplying good reasons..). If you have a vote on POI, as a sysmanager I don't vote on that. The only members that can intervene in your project (if that member role was there that is), could be the lawyers ;) En (or de)-cryption support in POI is something that could be appropiate on that ;)). Hope you get the overall picture of what I am trying to say here.. (please don't kill me on details..) Yeah the kicker is that there are no bugs in it (or at least there weren't a week or two ago). Maybe Turbine is perfect? :-D Dude.. I was searching my ass of on that crashing thing.. I guess it is perfect then indeed ;). Mvgr, Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 2002-05-25 at 11:38, James Taylor wrote: My projects haven't come to a grinding halt. Only on general @ jakarta But this isn't about your projects, it is about the community, and the community is more important than the code. Do you even know why you are here? No.. how about you enlighten me? -Andy -- jt (who is afraid Pier will do a mailing list search on him and realize how little value he brings to the community =) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 25 May 2002, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. What harm is James Todd doing ? Since there are 6 months from his last activity you can request the removal of his account - but I don't see why he ( or James Davidson or Anil ) should be removed for disappearing. If they'll never come back - that's fine and it doesn't hurts nobody. But their name remains listed in many source files and should remain in the list of commiters. Todd is still listed in @author tags in quite a few files ( used by both 3.x and 4.x - in tomcat-util package ). And there is nothing wrong with 9-5 contributions, there are many people who have jobs related with apache projects. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
James Taylor [EMAIL PROTECTED] wrote: -- jt (who is afraid Pier will do a mailing list search on him and realize how little value he brings to the community =) Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :) sarcasm Just need to grep the right files... You are a good committer, I see that you have 2342 commits into the turbine CVS. Good. I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so lazy), but hear hear, Costin has 25871, beating Craig who is just at 22712, and our president (Sam) at 60869... Yes yes, he deserves to be the PMC president just for that... This is such a nice way to recognized how much you contributed to the foundation, isn't it? Hints for newbies, make your CVS commits small, so your overall activity meter will grow. Two lines at a time, and if you have a nice file of 1000 lines, you get 500 points just for that... /sarcasm -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sat, 25 May 2002, Pier Fumagalli wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote: -1, its not broken, it worked. I see little reason to fix it. It is broken. We don't allow Sally Khudairi to be a member of this community, nor James Gonzo Todd (ex employee at Sun), to leave his employment and terminate his working (9 to 5) relationship with Apache, without leaving him with the dues of a committer and make him look bad because he disappeared. What harm is James Todd doing ? Since there are 6 months from his last activity you can request the removal of his account - but I don't see why he ( or James Davidson or Anil ) should be removed for disappearing. If they'll never come back - that's fine and it doesn't hurts nobody. But their name remains listed in many source files and should remain in the list of commiters. Todd is still listed in @author tags in quite a few files ( used by both 3.x and 4.x - in tomcat-util package ). And there is nothing wrong with 9-5 contributions, there are many people who have jobs related with apache projects. Being a committer (at least that's my idea), he doesn't only have the right to vote, but also the due to vote... This is one of the fundamental concepts of any good democratic country. Are we undermining that? Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Being a committer (at least that's my idea), he doesn't only have the right to vote, but also the due to vote... This is one of the fundamental concepts of any good democratic country. Are we undermining that? you also have the right to abstain. Sometimes you speak loudest by not speaking at all. Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Being a committer (at least that's my idea), he doesn't only have the right to vote, but also the due to vote... This is one of the fundamental concepts of any good democratic country. Are we undermining that? Hmm.. democracy is also having the right not to vote. Just don't complain if you don't like what happened after the vote.. Mvgr, Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
From: Pier Fumagalli [EMAIL PROTECTED] Being a committer (at least that's my idea), he doesn't only have the right to vote, but also the due to vote... This is one of the fundamental concepts of any good democratic country. Are we undermining that? No, it isn't. In a true democracy, one has the right to abstain. IMO that a good democracy doesn't need strong feelings: many dictators go to power with a strong vote with a strong turnout, while one of the major democracies of the world, the US, doen't surely have one of the highest turnouts. Just my 2euros. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Maven provides that functionality ;)) see http://jakarta.apache.org/turbine/maven/activity-log.html Mvgr, Martin On Sat, 2002-05-25 at 18:28, Pier Fumagalli wrote: James Taylor [EMAIL PROTECTED] wrote: -- jt (who is afraid Pier will do a mailing list search on him and realize how little value he brings to the community =) Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :) sarcasm Just need to grep the right files... You are a good committer, I see that you have 2342 commits into the turbine CVS. Good. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
while one of the major democracies of the world, the US, doen't surely have one of the highest turnouts. And a lot of people see that as a really bad thing. Turning in an empty ballot is one thing, but not going to the polls because you can't tear yourself away from 'Must See TV' is ignoring your responsibility as a citizen. -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
No, it isn't. In a true democracy, one has the right to abstain. IMO that a good democracy doesn't need strong feelings: many dictators go to power with a strong vote with a strong turnout, while one of the major democracies of the world, the US, doen't surely have one of the highest turnouts. For the record, technically the US is a democratic republic and not a Democracy. The low turnout in part reflects that. We vote *against* things not for them. Hence our representatives try to say next to nothing that they could get voted against on. (this isn't unpatriotic or a complaint, its just facts). As a test of this, be an incumbent and run on something that people are against, make a racist comment or something...you'll find your opponent does really well. For example. I did vote in the last presidential election, but it made little sense to do so. The electoral votes in North Carolina were decided LONG before I cast my ballet. So in a sense, when it came to actually picking the man, my vote actually did not count. (You vote for your states electors, the electors vote for the president...so if your electors vote for the other guy...well your vote meant nothing on the scale of things...if you don't win...your issues have to wait till next time) From my understanding, in most European parliamentary democracies, generally you vote for more issue-oriented parties. Even if you loose you take a certain number of seats. So it makes sense to vote regardless of whether its going to be a landslide. But as far as I know Jakarta is not a democracy...its a meritocracy. -Andy Just my 2euros. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
LOL ;-) On Sat, 2002-05-25 at 12:43, Martin van den Bemt wrote: Maven provides that functionality ;)) see http://jakarta.apache.org/turbine/maven/activity-log.html Mvgr, Martin On Sat, 2002-05-25 at 18:28, Pier Fumagalli wrote: James Taylor [EMAIL PROTECTED] wrote: -- jt (who is afraid Pier will do a mailing list search on him and realize how little value he brings to the community =) Sorry James, I just _had_ to do this! :) Nothing personal!!! :) :) :) sarcasm Just need to grep the right files... You are a good committer, I see that you have 2342 commits into the turbine CVS. Good. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Nicola Ken Barozzi [EMAIL PROTECTED] wrote: From: Pier Fumagalli [EMAIL PROTECTED] Being a committer (at least that's my idea), he doesn't only have the right to vote, but also the due to vote... This is one of the fundamental concepts of any good democratic country. Are we undermining that? No, it isn't. In a true democracy, one has the right to abstain. Correct... In every official Apache ballot (foundation crap, legal stuff), you always have three options: [ ] Yes [ ] No [ ] Abstain But I feel it's a due for all foundation members to at least tick one of those boxes (got upset with a couple of very close friends of mine because they didn't show up at the members meeting last week)... You can abstain, but you shouldn't ignore... higher-bandwidth language=italian Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o non andare a votare? /higher-bandwidth (Translated it would sound like: what's more right democratically speaking, going to poll booth and put in an unticked voter's card, or not even caring about going to vote? - But I don't know if it makes sense in English... Andy?) Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
its a meritocracy. Thanx to the Oxfort dictionary I know what it is.. But all democracies are actually meritocracies according to the dictionary, they select you to be able to vote when 18+. But this is getting way to Off-Topic I guess... ;)) Mvgr, Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 25 May 2002, Pier Fumagalli wrote: Just need to grep the right files... You are a good committer, I see that you have 2342 commits into the turbine CVS. Good. I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so lazy), but hear hear, Costin has 25871, beating Craig who is just at 22712, and our president (Sam) at 60869... Yes yes, he deserves to be the PMC president just for that... I don't think anyone can find a mail from Craig or Sam (or me) 'bragging' about the number of commits or how important of contribution we make and how people who contribute 'less' should pay attention. I respect Craig mostly for the quality of his code ( even if I prefer different solutions and we disagree on many other things ), I respect Sam the most for keeping a low-key as 'PMC president' ( I never saw him use the 'I'm the PMC chair' as an argument ). A smart idea ( like the try/catch unrolling ) is as important as 100s of commits fixing bugs or 100s of mails answering questions. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
From: Pier Fumagalli [EMAIL PROTECTED] Nicola Ken Barozzi [EMAIL PROTECTED] wrote: From: Pier Fumagalli [EMAIL PROTECTED] Being a committer (at least that's my idea), he doesn't only have the right to vote, but also the due to vote... This is one of the fundamental concepts of any good democratic country. Are we undermining that? No, it isn't. In a true democracy, one has the right to abstain. Correct... In every official Apache ballot (foundation crap, legal stuff), you always have three options: [ ] Yes [ ] No [ ] Abstain But I feel it's a due for all foundation members to at least tick one of those boxes (got upset with a couple of very close friends of mine because they didn't show up at the members meeting last week)... You can abstain, but you shouldn't ignore... higher-bandwidth language=italian Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o non andare a votare? /higher-bandwidth higher-bandwidth language=italian Democraticamente parlando, cos'e` piu` giusto, votare scheda bianca o non andare a votare? /higher-bandwidth Dipende dal messaggio che vuoi dare... (Translated it would sound like: what's more right democratically speaking, going to poll booth and put in an unticked voter's card, or not even caring about going to vote? - But I don't know if it makes sense in English... Andy?) I always thought that voters has at least a moral due to vote. But I have noted that when a democtratic system is sane, the percentages of the two major parties are similar. This keeps a healthy tension between them, that keeps the actions of the ruling party in control. I have also noted that high turnouts usually mean that the voters are upset by something, or that the vote is particularly important. These cases usually involve a lot of tensions. Out of these simple observations, I have cone not to disdain low turnouts, and appreciate the fact that there are really 4 votes: [ ] Yes [ ] No [ ] Abstain [ ] whatever Don't we have a similar system (the +-0 is even more)? +1 -1 +-0 no vote These votes are different in meaning: [ 3] Yes [ 1] No [ 10] Abstain [ 1] Whatever (I want you to take a decision on this matter, but I don't know what is best; please try to lobby the -1 or find a compromise) [ 3] Yes [ 1] No [1] Abstain [10] Whatever (I don't care whatever happens, you could even not decide on this issue and drop it: if there is a -1, don't mind lobbying too much, I will never back you) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 2002-05-25 at 12:53, Martin van den Bemt wrote: its a meritocracy. Thanx to the Oxfort dictionary I know what it is.. But all democracies are actually meritocracies according to the dictionary, they select you to be able to vote when 18+. But this is getting way to Off-Topic I guess... ;)) The action worthy of merit being: Surviving adolescence? Mvgr, Martin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
From: [EMAIL PROTECTED] On Sat, 25 May 2002, Pier Fumagalli wrote: Just need to grep the right files... You are a good committer, I see that you have 2342 commits into the turbine CVS. Good. I still beat you, overall I'm at 10717, Andy is at 2666 (Andy you're so lazy), but hear hear, Costin has 25871, beating Craig who is just at 22712, and our president (Sam) at 60869... Yes yes, he deserves to be the PMC president just for that... I don't think anyone can find a mail from Craig or Sam (or me) 'bragging' about the number of commits or how important of contribution we make and how people who contribute 'less' should pay attention. I respect Craig mostly for the quality of his code ( even if I prefer different solutions and we disagree on many other things ), I respect Sam the most for keeping a low-key as 'PMC president' ( I never saw him use the 'I'm the PMC chair' as an argument ). A smart idea ( like the try/catch unrolling ) is as important as 100s of commits fixing bugs or 100s of mails answering questions. If commit numbers are not so important (and I agree), then why measure them at all? BTW, this is not what you said some days ago: http://marc.theaimsgroup.com/?l=jakarta-generalm=102112907923436w=2 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 2002-05-25 at 19:03, Andrew C. Oliver wrote: The action worthy of merit being: Surviving adolescence? Too many words I need a dictionary for ;)) (it's hard to discuss stuff you have to get out of a dictionary, so I will not try that) I will conclude this day of way too little coding by using the footer I just seen on Nicola's mail : - verba volant, scripta manent - (discussions get forgotten, just code remains) Let's I made the choice to remain ;). Mvgr, Martin van den Bemt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Nicola Ken Barozzi [EMAIL PROTECTED] wrote: If commit numbers are not so important (and I agree), then why measure them at all? If commit numbers are not so important (and I agree), what is the way that this community has to decide whether a person is a committer or not, given that as it is today, you're not recognized as a member of this community if you don't have a CVS account, and your name is not listed in $CVSROOT/avail Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
From: Pier Fumagalli [EMAIL PROTECTED] Nicola Ken Barozzi [EMAIL PROTECTED] wrote: If commit numbers are not so important (and I agree), then why measure them at all? If commit numbers are not so important (and I agree), what is the way that this community has to decide whether a person is a committer or not, given that as it is today, you're not recognized as a member of this community if you don't have a CVS account, and your name is not listed in $CVSROOT/avail What is the way that *any* community decides in voting? You *are* a member of the community even if you do not have an account. http://xml.apache.org/roles.html : Developers Developers are the people who write code or documentation patches or contribute positively to the project in other ways. A developer's contribution is always recognized. In source code, all developers who contribute to a source file may add their name to the list of authors for that file. A developer *is* part of the community. This is how it works on the Cocoon, Forrest and POI projects AFAIK. It seems that you are trying to put on paper that developers that are not committers have to be listed. It can be done, but why? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
From: Pier Fumagalli [EMAIL PROTECTED] Nicola Ken Barozzi [EMAIL PROTECTED] wrote: What is the way that *any* community decides in voting? You *are* a member of the community even if you do not have an account. http://xml.apache.org/roles.html : Developers Developers are the people who write code or documentation patches or contribute positively to the project in other ways. A developer's contribution is always recognized. In source code, all developers who contribute to a source file may add their name to the list of authors for that file. A developer *is* part of the community. This is how it works on the Cocoon, Forrest and POI projects AFAIK. It seems that you are trying to put on paper that developers that are not committers have to be listed. It can be done, but why? Nicola, you might as well ask Stefano who wrote that page... I want to point out one little paragraph below the one you mentioned: A Committer has write access to the source code repository and gains voting rights allowing them to affect the future of the subproject. A developer, at the end of the day, doesn't have the right to vote. When it comes to numbers, he is worth less than zero... I'm sorry, but this is how OUR reality is right now, because we didn't think about it in the first place when this project (or XML) were founded (and you can trust me because I was there, both times)... It does have the right to vote, but it's not binding (at least this is what Stefano told me two weeks ago). I don't want developers that are not committers to vote: a vote is important for the future of the project, and the future of Apache. Should we give votes to developers that are not interested in the future of Apache? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
From: Pier Fumagalli [EMAIL PROTECTED] Nicola Ken Barozzi [EMAIL PROTECTED] wrote: It does have the right to vote, but it's not binding (at least this is what Stefano told me two weeks ago). I don't want developers that are not committers to vote: a vote is important for the future of the project, and the future of Apache. Should we give votes to developers that are not interested in the future of Apache? Nope, we shouldn't but we should give it to those who ARE interested in the future of Jakarta, or XML, and _do_stuff_ for those project, but are not bound to a particular codebase. In cocoon, we have a documentation team now. Documentation is in CVS. IMO all should be in CVS, which is the project store, or the mailing lists. We should change our meter from being you contribute CODE to the project, to you contribure WORK to the project. You contribute work? Ok, then you become a committer, that gets the *right* to use the CVS, not the *need*. If we trust him, why not give him CVS commit access? I don't understand what rights you want to give to these developers but not committers. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 25 May 2002, Nicola Ken Barozzi wrote: I respect Craig mostly for the quality of his code ( even if I prefer different solutions and we disagree on many other things ), I respect Sam the most for keeping a low-key as 'PMC president' ( I never saw him use the 'I'm the PMC chair' as an argument ). A smart idea ( like the try/catch unrolling ) is as important as 100s of commits fixing bugs or 100s of mails answering questions. If commit numbers are not so important (and I agree), then why measure them at all? BTW, this is not what you said some days ago: http://marc.theaimsgroup.com/?l=jakarta-generalm=102112907923436w=2 I believe my message is: http://marc.theaimsgroup.com/?l=jakarta-generalm=102130834717179w=2 And I said exactly the same thing, that small commits are easier to review and putting a 'ranking' on a commiter ( by any criteria ) is bad ( not only number of commits - also age, how long he is commiter, how many flame-wars he participates in or how many bugs he fixes, or anything else ). What it matter is that he moves the project forward and contributes his time and inteligence to the community. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 25 May 2002, Pier Fumagalli wrote: Nope, we shouldn't but we should give it to those who ARE interested in the future of Jakarta, or XML, and _do_stuff_ for those project, but are not bound to a particular codebase. We should change our meter from being you contribute CODE to the project, to you contribure WORK to the project. AFAIK each project can decide and vote to give rights to anyone they feel deserve it and puts work in the project. There is no requirement that the work is Java or C - I think there are people who focus more on documentation and became commiters for that. It's up to each project to decide by the normal rules. If you want to propose a lawyer to become commiter on tomcat - I'll be more than +1 ( we need one to solve the mystery of the JMX and other licences, and that would be an important contribution and worth of making him commiter ). I don't think that having CVS access ( without knowing what CVS is ) will be a problem for him. And if he cares or not to vote - again I don't care. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Committer access and responsibilities...
De: Pier Fumagalli [mailto:[EMAIL PROTECTED]] Enviado el: sábado 25 de mayo de 2002 19:52 If commit numbers are not so important (and I agree), what is the way that this community has to decide whether a person is a committer or not, given that as it is today, you're not recognized as a member of this community if you don't have a CVS account, and your name is not listed in $CVSROOT/avail Pier I Disagree completely.. Mail archives prove you wrong, althought many of the more vocal people here are committers, nothing blocks anyone to give his opinion and his vote,more this same thread proves you wrong too, i can remember someone someone was proposed last time as PMC member without being a committer.. I'm not the oldest here, 2'5 years, and my contributions are not bigger, but all i can say from the history i know, that you are simply suffering some kind of father syndrome, like those fathers that, when his children grow up, doent want to loose the control they have over his lifes. Your children is starting to be teenager, and hence dont feels his father is so important or has the reason everytime, nor that is the better and in addition is a little castrating as every father.. Well time will get you to the right place.., now your children is walking on the avenue ( making a girlfriend!!! :) and sometimes in the future, you will get a friendship with him and he will learn to respect you.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] Committer access and responsibilities...
Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So the major topic of discussion is that I perceive a substantial difference between being able to commit code to a CVS repository, and being a committer committer, with all dues and responsibilities that this role concerns... For example sometimes someone might want to have commit access just because he is working for a company that deals with a particular project in Apache (we've seen this happening several times with some projects such as Xerces and Tomcat), but he really doesn't care about the whole fuzz of Apache and stuff, and once the employment contract ends, the relationship with Apache terminates as well (I don't need to enumerate all those examples along those lines). One other example, if we didn't have Henri building RPMs for basically all Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, don't you think that he would deserve committer status even if he's not tied to any particular codebase? We had this problem in the current election of the members, Sally Khudairi: Sally doesn't code, but she was involved with the ASF since before it was even created as a press organizer. Does she deserve to be a member of the foundation? Even if she doesn't code? Yes she does, IMO (and she was elected and nominated a member today)... So, IMO, there's a great difference between being a coder, and being a member of the Jakarta community, at least in my opinion. There might be coders who are not involved with the community, and there might be non-coders who are much involved with it, want to participate, are active and deserve to be committers... Our current structure doesn't allow that to happen, both things. If you need to write code in a particular source-base, and you need CVS access, you are automagically made a committer, even if you don't care about much else, and if you're very much involved with the overall project, but not tied to ANY whatsoever codebase, and really, don't want / can't do it. So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). I believe this makes sense, more sense than what we have now, also because we've seen that happening in the ASF for the very first time with a non-coding member. Comments please? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
+1. Another example if I could. The job role of 'Java admin' is growing more and more at companies. Developers shouldn't be adminning things, but would you have your unix or oracle admin be the admin of the Java side with zero Java knowledge? Jakarta houses the 'Java' community at Apache but there's no way for a Java admin to be a part of that community. Helping other admins, writing documentation, being a consumer at the coders. The only way it can happen is if they become a coder, and that's contrary to the concept of a Java admin. I think Pier's suggestion will help to grow the 'ownership' of the projects and the apache way of thinking to a larger audience. Some possible negatives: With more non-codery people around, will the 'noise' level in mail lists be too high for coders to want to pay attention? [It already is getting that way I find. I delete entire threads if the first couple of mails are not of interest to me. It has to be retitled as with this email to make me realise there was more going on than the original mails. ] By growing a large community of non-coders, the coders could have less say in the product. Is this good/bad? How would the +1/-1 system work. Would votes be open to committers only in some instances, and to non-committing members only in others. Who votes membership vs committership vs contributorship? None of them that hard to answer I imagine. Hen On Sat, 25 May 2002, Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
-1, its not broken, it worked. I see little reason to fix it. On Fri, 2002-05-24 at 21:11, Henri Yandell wrote: +1. Another example if I could. The job role of 'Java admin' is growing more and more at companies. Developers shouldn't be adminning things, but would you have your unix or oracle admin be the admin of the Java side with zero Java knowledge? Jakarta houses the 'Java' community at Apache but there's no way for a Java admin to be a part of that community. Helping other admins, writing documentation, being a consumer at the coders. The only way it can happen is if they become a coder, and that's contrary to the concept of a Java admin. I think Pier's suggestion will help to grow the 'ownership' of the projects and the apache way of thinking to a larger audience. Some possible negatives: With more non-codery people around, will the 'noise' level in mail lists be too high for coders to want to pay attention? [It already is getting that way I find. I delete entire threads if the first couple of mails are not of interest to me. It has to be retitled as with this email to make me realise there was more going on than the original mails. ] By growing a large community of non-coders, the coders could have less say in the product. Is this good/bad? How would the +1/-1 system work. Would votes be open to committers only in some instances, and to non-committing members only in others. Who votes membership vs committership vs contributorship? None of them that hard to answer I imagine. Hen On Sat, 25 May 2002, Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com - software solutions for business http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in Java http://krysalis.sourceforge.net/centipede - the best build/project structure a guy/gal could have! - Make Ant simple on complex Projects! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
-1 If someone doesn't want to be involved in the voting - he can do exaclty that, abstain. If someone doesn't want to support a particular release - he can abstain from the release vote( or vote +-0 ). If you spend time and write code for a project and are willing to maintain/support - and if the people on the project vote you in, you have the same rights as all the other people on that project. I do agree ( and I advocated for this a lot ) on lowering ( or eliminating) the walls between projects, so jakarta commiters can commit code in any jakarta project ( subject to the normal project rules ). Some people didn't agree with that even for commons, and I accepted the fact. If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Costin On Sat, 25 May 2002, Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So the major topic of discussion is that I perceive a substantial difference between being able to commit code to a CVS repository, and being a committer committer, with all dues and responsibilities that this role concerns... For example sometimes someone might want to have commit access just because he is working for a company that deals with a particular project in Apache (we've seen this happening several times with some projects such as Xerces and Tomcat), but he really doesn't care about the whole fuzz of Apache and stuff, and once the employment contract ends, the relationship with Apache terminates as well (I don't need to enumerate all those examples along those lines). One other example, if we didn't have Henri building RPMs for basically all Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, don't you think that he would deserve committer status even if he's not tied to any particular codebase? We had this problem in the current election of the members, Sally Khudairi: Sally doesn't code, but she was involved with the ASF since before it was even created as a press organizer. Does she deserve to be a member of the foundation? Even if she doesn't code? Yes she does, IMO (and she was elected and nominated a member today)... So, IMO, there's a great difference between being a coder, and being a member of the Jakarta community, at least in my opinion. There might be coders who are not involved with the community, and there might be non-coders who are much involved with it, want to participate, are active and deserve to be committers... Our current structure doesn't allow that to happen, both things. If you need to write code in a particular source-base, and you need CVS access, you are automagically made a committer, even if you don't care about much else, and if you're very much involved with the overall project, but not tied to ANY whatsoever codebase, and really, don't want / can't do it. So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all the privileges and dues of a contributor (having CVS access, and overlooking the code he's contributing to) and of a member (can vote for PMCs, should participate and contribute to discussions on the overall structure of Jakarta). I believe this makes sense, more sense than what we have now, also because we've seen that happening in the ASF for the very first time with a non-coding member. Comments please? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Henri Yandell [EMAIL PROTECTED] wrote: +1. Another example if I could. The job role of 'Java admin' is growing more and more at companies. Developers shouldn't be adminning things, but would you have your unix or oracle admin be the admin of the Java side with zero Java knowledge? Jakarta houses the 'Java' community at Apache but there's no way for a Java admin to be a part of that community. Helping other admins, writing documentation, being a consumer at the coders. The only way it can happen is if they become a coder, and that's contrary to the concept of a Java admin. That's where my career is going to lately, I didn't think about that in the first place. I'm going to loose my committer status soon now that you make me think about it! :) :) :) I think Pier's suggestion will help to grow the 'ownership' of the projects and the apache way of thinking to a larger audience. Thanks... Some possible negatives: With more non-codery people around, will the 'noise' level in mail lists be too high for coders to want to pay attention? [It already is getting that way I find. I delete entire threads if the first couple of mails are not of interest to me. It has to be retitled as with this email to make me realise there was more going on than the original mails. ] That might as well happen, although I don't feel that there will be many in one of the two categories without being a committer. Probably a some more in the contributor side of things (because of corporate involvement and stuff), but not the other way around... But I believe that we shouldn't give up this option... By growing a large community of non-coders, the coders could have less say in the product. Is this good/bad? How would the +1/-1 system work. Would votes be open to committers only in some instances, and to non-committing members only in others. Who votes membership vs committership vs contributorship? Regarding votes, I believe that the votes for a particular codebase should be open only to contributors only of that particular codebase, and that's it (I'm not going to vote on Ant for example, or Turbine)... Votes regarding accepting new codebases, starting new subprojects, electing the PMC, that should go only to members, not contributors... My stance would be that if you start off being a contributor, no question asked (from that point of view)... Patch contribute, do all you want and need, you have fun? You want to spend more time on it and Jakarta is not only something you're paid to work on? Kewl, just ask, could be fairly automatic, it might as well happen automatically if someone nominates you to do that... I don't think that a vote is even necessary to promote a committer who wants to be a contributor, talk with someone who can sponsor you, and I'll be fine... For the ones who want to start as member, the procedure to become a committer on one particular projects are already there, as if I wanted to start giving some patches to (for example) Ant, and get involved with that codebase... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I do agree ( and I advocated for this a lot ) on lowering ( or eliminating) the walls between projects, so jakarta commiters can commit code in any jakarta project ( subject to the normal project rules ). Some people didn't agree with that even for commons, and I accepted the fact. Over my dead body. If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Hola, you tend to forget a part I'm stressing out quite hardly... It's not only rights... It's also dues, right? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
On Sat, 25 May 2002, Pier Fumagalli wrote: If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. Hola, you tend to forget a part I'm stressing out quite hardly... It's not only rights... It's also dues, right? Yes, the 'due' to spend weekends writing code or answering emails or reading flame wars. Give me a break with the big 'due' to vote or have a say over how the project you're involved with. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Committer access and responsibilities...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] If you are a commiter - you have the same rights with all other commiters. If you don't want to exercise some rights - it's your choice. But it's not just about exercising rights, it's also about granting rights. At the moment, you cannot grant someone one right (commit access) without also granting them additional rights (voting etc). Some people (myself included) would claim that the condition of entry for those rights, are not equal. In that case, where do you set the bar? At the bottom or the top? It seems that that is where this discussion really came from. Pier set it at the top (the code might be good, but he wasn't going to grant someone full committer rights based solely on that), while you set it closer to the bottom (the code deserved commit access, and that implies the other rights). Personally I'm -0 on this. I don't think commit access should be so widely given out, because I think that the developer communities should be larger than the set of committers. The voting rules allow for the casting of non-binding votes, but they tend not to be used much. It's fairly easy for non-committers to submit patches, but that puts a responsibility onto the committers to apply them in a timely fashion. I'm not a committer on any (sub)project, but I don't think that should stop me participating and expressing non-binding opinions. The community is open to non-committers, and you/we should be encouraging that. Why the rush to vote people in? There's a number of things that the committer status gives - which ones are being targeted? If all you're trying to do is avoid having to apply their patches for them, then that's a different discussion (i.e. How do you improve the patch-submit-apply process). If you think that he project needs to include the opinions/ideas of more people, then listen to the non-binding votes. I would think that making someone a committer is done in the anticipation that they will become a core member of the tomcat Jakarta communities. The commit/voting rights are just a side effect of that. -- NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]