Re: Rules for Revolutionaries
Sam Ruby wrote: Ovidiu Predescu wrote: I'm glad this actually didn't happen, since it took a long time for the 4.0 branch to become stable and usable. If it weren't for the legacy codebase being continually developed, we would have been stuck with a slow 3.2 and a buggy 4.0. I've used Tomcat 3.3 for more than a year before switching to 4.1, and I liked 3.3 a lot for its speed and features. What would have been more likely to happen is that Tomcat 3.3 would have continued on SourceForge, been known by a different name, had a fully supported servlet 2.3 facade, and would have been known as the production quality servlet engine. Of course, it could had been a funny thing :) You should also remember that our friend Pier make many remarks about stability on tomcat 4.x and proposed sometimes ago on tomcat-dev to start a fork to make a minimal but more stable TC 4.X In retrospect, I think the decision to continue the development on both Tomcat versions was a good one. It let the time solve the frictions. The result is that now we have a very mature Tomcat community, and little of the past problems are reflected today on the mailing list. I agree, if at anytime, TC 3.3.x was said as obsolete or to be discontinued, I'll had to choose an alternate servlet engine since TC 3.2 was too slow and memory consuming and TC 4.x still not production ready. But the good thing in making TC 3.3 and 4.x teams continuing their own works was that Tomcat 5 get the best of both part, and was really quickly launched using jakarta-tomcat-connectors as a common sandbox. Sometimes, when you let 2 teams works in parallel on similar project but different implementation, you avoid that one team fly to another umbrella (ie sf.net) and sus save the community and also you could help making the next revolution by merging good ideas from both projects.
Re: Rules for Revolutionaries
Costin Manolache wrote: If you don't need or care about something - it doesn't mean you should vote -1 on it. If 3 fellow commiters are voting +1 - then probably there is a real need or issue. I don't think anyone voted -1 on a 4.0 release, and nobody voted -1 on the 3.3 release ( if I remember correctly ). No TC 3.3 team members voted +0 for 4.0 release and 4.0 members voted +0 for 3.3 release, and if you remember each team congratulated the other one for their release ;) BTW, keeping the both team working on each project has saved the tomcat-dev commiters community which should be the goal of Apache isn't it ?
Re: Rules for Revolutionaries
Jeff Turner wrote: On Tue, Nov 12, 2002 at 04:05:24AM +0100, Stefano Mazzocchi wrote: ... I still disagree. The rules of revolutionaries *MUST* (I repeat *MUST*!!!) protect the identity of the project more than they protect the freedom of innovation of the single developers. More than anything else, the fact that two different codebases were *released* with the same name at the same time, pissed many people off (myself included) and created a lot of problems in the users. Like? How many users do you see complaining because they have a choice? Personally, I find Tomcat 4's startup time is too slow for Forrest/Cocoon development, so if it wasn't for 3.3.x, I'd be using Resin or Jetty. You could speed up TC 4 startup time by : 1) comments mbeans support in top of server.xml : !-- Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ -- 2) Remove the admin and manager webapps which also take some time to initialize. Regards.
Re: Rules for Revolutionaries
Daniel Rall wrote: Do you really think that Tomcat 4's startup time would've remained significantly worse than 3.3.x if those working on 3.3.x had migrated to working on 4? They wouldn't have. They would have migrated to SourceForge. That's the problem with an all volunteer army. The can't be trusted to do as they are told. - Sam Ruby
Re: Rules for Revolutionaries
They wouldn't have. They would have migrated to SourceForge. That's the problem with an all volunteer army. The can't be trusted to do as they are told. so don't tell them. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries
Joe Schaefer wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: I believe it was a mistake to allow two different codebases to share the same name. I'm not convinced that having two codebases is necessarily a mistake. it's not the multiple codebases that's the issue; it's that they both had the same name and both continued active development. as a counterexample, both httpd 1.3 and 2.0 were in concurrent active development for a long time. 1.3 development slowed down, and when 2.0 was finally released, 1.3 went into a sort of maintenance mode -- meaning that bugfixes and minor backported features can show up in it, but nothing that doesn't also appear in 2.0 at the same time. i'm not familiar with the data around the tomcat issue, just the metadata, but i'm getting the feeling that major divergent feature enhancement was occurring in both branches. (e.g., something might be added to tomcat 3 that wasn't (and won't be) in tomcat 4). is that correct, or a misunderstanding on my part?
Re: Rules for Revolutionaries
Costin Manolache wrote: What you would have liked is your problem. As I repeated quite a few times and you don't seem to hear is that the decision about a release is a majority vote and can't be vetoed - even if it pisses off some people. not strictly true, although mostly. a product release may be effectively vetoed by the asf officer with oversight of the project, if it appears in that person's judgement that releasing it would be the Wrong Thing for the foundation. in that case, it doesn't matter what the majority think, since the product is an *asf* product and not just theirs, although they certainly have the privilege of and responsibility to try to convince the officer (pmc chair) of the Rightness of the view to release. in a healthy and smoothly-communicating community that should never happen; any such horribly blocking issue should have been raised and a reasonable solution or compromise developed. in fact, this hasn't happened afaik, and i hope it never does -- but everyone should be aware that this is one of the aspects of people working on code owned in common by the foundation proper: the foundation has the final say about it. the interests of the foundation are represented by the asf officer overseeing the project, who is almost certainly going to support the majority -- except when doing so would damage the foundation's interests. this is all imo, and certainly others may disagree with me.
Re: Rules for Revolutionaries
Rodent of Unusual Size wrote: Jeff Turner wrote: On Tue, Nov 12, 2002 at 04:05:24AM +0100, Stefano Mazzocchi wrote: ... More than anything else, the fact that two different codebases were *released* with the same name at the same time, pissed many people off (myself included) and created a lot of problems in the users. Like? How many users do you see complaining because they have a choice? How many users have downloaded the latest stable release? Oh, bye the way - what is that the product version number I should recommend ? :-) Cheers, Steve. i have seen a few -- a very few, but greater than zero -- messages sent to the main apache address that indicated some confusion about this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
Re: Rules for Revolutionaries
On Monday, Nov 11, 2002, at 19:05 US/Pacific, Stefano Mazzocchi wrote: Quoting Costin Manolache [EMAIL PROTECTED]: Thanks for answering this, it is really helpful. On Sat, 2002-11-09 at 04:25, Stefano Mazzocchi wrote: 3) is it true that Tomcat 3.3 was released *after* tomcat 4.0 was release and that was *not* a bugfix release but an alternative development branch? True ( released after, not a bugfix - it wasn't a branch but the trunk for 3.x ). Tomcat 3.3 release also had a majority of the tomcat-dev community. Most people working on 4.0 voted +-0 or abstained - and the same happened when 4.0 was released, with people working on 3.3 abstaining. As I said - the majority controls the name and the release. A majority of tomcat committers can vote to make a release called Tomcat-anything, and the release can't be vetoed. There is something wrong here and I hope you get to see it: the community majority can't vote for a revolution *and* vote for new release of the old branch. It doesn't make any difference whatsoever. When a revolution is voted and accepted, no new release which is not a bugfix can be accepted. Period. Why? because there can't be *two* different projects using the same name. This is a bit too strong. Given the alternative, an irreversible split of the two communities, I think the solution was the only acceptable one at that time for everybody involved. There is no way you can convince people they should drop whatever they've been working on for years. And enforcing a strict rules is a bit out of place in an open-source community, where we usually have no regard to authority, but to common-sense and respect. Some thing were very different ( target VM, hooks, size/features trade-off ). Other things started different but become identical ( facades for example ). That's the whole point of a revolution - to improve the community and the code. One thing is very sure - we learned a lot from each other, and that wouldn't have been true if one set moved out. Acknowleged. This is why I think the rules for revolutionaries just work. But this doesn't mean that they can't be improved and this is *exactly* what I'm doing right now: trying to find a way to avoid the problems and negative friction that that tomcat revolution created. I'm not sure we can avoid this type of situations since each time they'll have something unique. There is a reason why history repeats itself: people never learn from other's experience, they have to experience it themselves. I don't think we should spend our time thinking of ways to fix this, just let thing happen and we'll deal with them at that time. AFAIK there's no situation like this right now, so what are trying to fix? To answer one unasked question - a majority vote on a revolution branch doesn't mean everyone is required to abandon other revolutions or the main trunk and work on the new codebase. I *strongly* disagree. After the majority of the community expressed a vote on a revolution, the old codebase *lost* the status of being actively maintained and, in order to continue, should have been filed for *another* proposal, with *another* codename and *without* the ability to make releases. I'm glad this actually didn't happen, since it took a long time for the 4.0 branch to become stable and usable. If it weren't for the legacy codebase being continually developed, we would have been stuck with a slow 3.2 and a buggy 4.0. I've used Tomcat 3.3 for more than a year before switching to 4.1, and I liked 3.3 a lot for its speed and features. It would have solved *much* of the negative feelings that the tomcat community was spreading around the ASF at that time. Not so, that would have been an example of how Apache should not work. Whatever we do is for fun and peer acknoledgement, not because some authority tells us what and how to do it. Probably we would have had people leaving the community. Look at what happened in the not so distant past in the Emacs community, where Stallman imposed his points of view regarding how Emacs should look. People were pissed of and forked off XEmacs. Both are still in use today, and although they share very little in the underlying C code, higher level Lisp programs still work on both versions. It just means the revolution is accepted and can move out of proposal state and be released using the project name. Other revolutions can happen at any time. I still disagree. The rules of revolutionaries *MUST* (I repeat *MUST*!!!) protect the identity of the project more than they protect the freedom of innovation of the single developers. So how would you have decided which version to be named Tomcat? The old one which was named like that since the beginning, or the new one, which had nothing to do with the old source code base? Either way you chose, you'd have ended up pissing off the other camp. More than anything else, the fact that two different codebases were *released* with the same name
Re: Rules for Rule-making (Re: Rules for Revolutionaries)
On Tue, Nov 12, 2002 at 10:18:43AM -0500, Andrew C. Oliver wrote: ... Then we can all get back to coding, instead of worrying that some busybodies on this list are hatching a top-down Apache Bureaucracy for us to live in. +0 -- that is not the ONLY reason for being on this list. That was A reason for being on the REORG list but hopefully you're hear also to build stronger cross-apache ties and get to know your fellow committers and whats going on elsewhere for the good of creating a stronger community. :) Sorry, it was an unfairly harsh comment.. --Jeff
Re: Rules for Revolutionaries
Stefano Mazzocchi [EMAIL PROTECTED] writes: [...] I believe it was a mistake to allow two different codebases to share the same name. I'm not convinced that having two codebases is necessarily a mistake. So far the discussion here seems to have centered around the concerns of the existing tomcat developers. I'd like to know what the tomcat users (ie. the future tomcat developers) think of the 3.x/4.x division. -- Joe Schaefer
Re: Rules for Revolutionaries
On Tue, 2002-11-12 at 07:25, Stefano Mazzocchi wrote: Here is what I would have liked to see happening in Tomcat: What you would have liked is your problem. As I repeated quite a few times and you don't seem to hear is that the decision about a release is a majority vote and can't be vetoed - even if it pisses off some people. A vote on a feature or revolution doesn't mean the end of other features or codebases. As long as each codebase can gather a majority vote - things are going well. There are people who can vote +1 on more than one release and codebase. What's important is that most of the people who vote +1 on a codebase don't automatically vote -1 on the other codebase - which is the real solution. If you don't need or care about something - it doesn't mean you should vote -1 on it. If 3 fellow commiters are voting +1 - then probably there is a real need or issue. I don't think anyone voted -1 on a 4.0 release, and nobody voted -1 on the 3.3 release ( if I remember correctly ). And I think the same should apply to other apache projects, even older ones. Costin
Re: Rules for Revolutionaries
On Fri, 8 Nov 2002, Stefano Mazzocchi wrote: Date: Fri, 08 Nov 2002 23:48:39 + From: Stefano Mazzocchi [EMAIL PROTECTED] Reply-To: community@apache.org To: community@apache.org Subject: Re: Rules for Revolutionaries Costin Manolache wrote: In my personal opinion they are just redundant :-) The rule that matter is that the community control the code and the name - a majority vote in the community can decide ultimately what happens. Agreed. At the same time, I would love to see something written down about 'how the ASF guidelines are'. They might not be binding, just recommendations, but I think this will help a lot communities becaue these guidelines are distilled after years of try/fail cycles (and lot of pain!) A slightly more formal way to do this would be to explicitly canonicalize Apache Way policies like this at the apache.org level, and these automatically become the default policies for any Apache project unless that project deliberately (perhaps within some limits TBD) chooses to operate differently. The requirement for following these (or specializing them) would be an explicit part of a new project's charter. Essentially, this would be a generlization of the way Jakarta projects deal with coding style conventions -- there's a default (from the original Sun coding standards) that is the assumed standard unless a different choice is explicitly made and documented for a particular subproject. The same principle can be applied recursively -- instead of subclasses formally inheriting methods and instance variables (with the option to override), projects and subprojects formally inherit culture and standards unless they explicitly choose to override :-). I'd bet many people perceive that Apache actually works this way; let's just make that perception into reality. Craig
DOH! Re: Rules for Revolutionaries
Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this... Andrew C. Oliver wrote: A slightly more formal way to do this would be to explicitly canonicalize Apache Way policies like this at the apache.org level, and these automatically become the default policies for any Apache project unless that project deliberately (perhaps within some limits TBD) chooses to operate differently. The requirement for following these (or specializing them) would be an explicit part of a new project's charter. yes. Canons are way more efficient than trust and community building. I mean a tight nit group of people whom respect each other and want to work together is NO match for a group of people who don't respect each other and barely want to work together with a set of canon laws. (or should their be three n's in that) Essentially, this would be a generlization of the way Jakarta projects deal with coding style conventions -- there's a default (from the original Sun coding standards) that is the assumed standard unless a different choice is explicitly made and documented for a particular subproject. Yes, bracket placement is the most important issue in a community. If you don't use KR style bracketing I just can't read your code and the project is a total wash. ;-) Fortunately Eclipse lets me reformat it going in and reformat it going out. The same principle can be applied recursively -- instead of subclasses formally inheriting methods and instance variables (with the option to override), projects and subprojects formally inherit culture and standards unless they explicitly choose to override :-). Yes standards have worked so nicely in the software industry. Why we have several standards for any one thing. Its certainly better than mutual respect.. For as long as one follows one of the standards, it must be good. I'd bet many people perceive that Apache actually works this way; let's just make that perception into reality. In order to do this, lets set at least 6 months aside each to draft a large legal document, assign penalties for breaking any of the rules. We'll create a new subproject for Those who have not joined the shining path to enlightenment for projects choosing not to ratify the canon. Next we can create a interperator subproject, in the event of a disagreement among parties in a project the interperator (think of them as lawyers) can be assigned to help interperate the canon and apply penalities to whomever is judged to be in the wrong. The alternative is to get back the the basics...community, mutual respect, dare I say friendship, working for the best ideas, etc. Rigid guidelines are much easier than that. Thats why XP is such crap, a metaphor instead of a BUFD. Same prinicipal. Long live the SDLC! -Andy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DOH! Re: Rules for Revolutionaries
Tip: Start, run, notepad enter Copy Paste from the mail Type Save it Sleep on it make the real reply. ;) If you reply to me, just make the reply :). I like sarcasme and I don't have to read between the lines to figure out what the hell you really meant.. Mvgr, Martin -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED] Sent: Saturday, November 09, 2002 02:03 To: community@apache.org Subject: DOH! Re: Rules for Revolutionaries Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this... Andrew C. Oliver wrote: A slightly more formal way to do this would be to explicitly canonicalize Apache Way policies like this at the apache.org level, and these automatically become the default policies for any Apache project unless that project deliberately (perhaps within some limits TBD) chooses to operate differently. The requirement for following these (or specializing them) would be an explicit part of a new project's charter. yes. Canons are way more efficient than trust and community building. I mean a tight nit group of people whom respect each other and want to work together is NO match for a group of people who don't respect each other and barely want to work together with a set of canon laws. (or should their be three n's in that) Essentially, this would be a generlization of the way Jakarta projects deal with coding style conventions -- there's a default (from the original Sun coding standards) that is the assumed standard unless a different choice is explicitly made and documented for a particular subproject. Yes, bracket placement is the most important issue in a community. If you don't use KR style bracketing I just can't read your code and the project is a total wash. ;-) Fortunately Eclipse lets me reformat it going in and reformat it going out. The same principle can be applied recursively -- instead of subclasses formally inheriting methods and instance variables (with the option to override), projects and subprojects formally inherit culture and standards unless they explicitly choose to override :-). Yes standards have worked so nicely in the software industry. Why we have several standards for any one thing. Its certainly better than mutual respect.. For as long as one follows one of the standards, it must be good. I'd bet many people perceive that Apache actually works this way; let's just make that perception into reality. In order to do this, lets set at least 6 months aside each to draft a large legal document, assign penalties for breaking any of the rules. We'll create a new subproject for Those who have not joined the shining path to enlightenment for projects choosing not to ratify the canon. Next we can create a interperator subproject, in the event of a disagreement among parties in a project the interperator (think of them as lawyers) can be assigned to help interperate the canon and apply penalities to whomever is judged to be in the wrong. The alternative is to get back the the basics...community, mutual respect, dare I say friendship, working for the best ideas, etc. Rigid guidelines are much easier than that. Thats why XP is such crap, a metaphor instead of a BUFD. Same prinicipal. Long live the SDLC! -Andy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries
Craig R. McClanahan wrote: Agreed. At the same time, I would love to see something written down about 'how the ASF guidelines are'. They might not be binding, just recommendations, but I think this will help a lot communities becaue these guidelines are distilled after years of try/fail cycles (and lot of pain!) A slightly more formal way to do this would be to explicitly canonicalize Apache Way policies like this at the apache.org level, and these automatically become the default policies for any Apache project unless that project deliberately (perhaps within some limits TBD) chooses to operate differently. The requirement for following these (or specializing them) would be an explicit part of a new project's charter. i'm working on it; there's too much good stuff and too many good ideas coming too quickly for me to keep up easily. :-)
Re: DOH! Re: Rules for Revolutionaries
On Fri, 8 Nov 2002, Andrew C. Oliver wrote: Date: Fri, 08 Nov 2002 20:03:07 -0500 From: Andrew C. Oliver [EMAIL PROTECTED] Reply-To: community@apache.org To: community@apache.org Subject: DOH! Re: Rules for Revolutionaries Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this... Actually, I quite enjoyed the reply :-). And the cautions you raise are definitely relevant. You can over-engineer anything, including a community. But you can also under-engineer, and I get the impression that's sort of where we are right now. Craig
Re: DOH! Re: Rules for Revolutionaries
The scary part is that all of us who have been flamed by Andy now need to wonder what the first version of those messages looked like! Yikes! grin -- jt On Fri, 2002-11-08 at 20:03, Andrew C. Oliver wrote: Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this...
Re: DOH! Re: Rules for Revolutionaries
On 8 Nov 2002, James Taylor wrote: Date: 08 Nov 2002 20:56:50 -0500 From: James Taylor [EMAIL PROTECTED] Reply-To: community@apache.org To: community@apache.org Subject: Re: DOH! Re: Rules for Revolutionaries The scary part is that all of us who have been flamed by Andy now need to wonder what the first version of those messages looked like! Yikes! It's funny ... I started reading his reply without noticing who the author was, but I immediately figured it out ... yep, that's Andy! :-) grin -- jt Craig On Fri, 2002-11-08 at 20:03, Andrew C. Oliver wrote: Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries
Rodent of Unusual Size wrote: no, not if the revolutionary code is never accepted back into the main branch. if it isn't merged back in, it *isn't* part of the product and release; it remains a branch, or maybe gets forked into a completely separate product. Revolutionary code can become the main branch. Catalina became Tomcat 4. vetoed never makes it into a release. at least it had better not. it might end up in a branch or fork where it hasn't been vetoed, but that would be a different product with its own release. The key question here - if there truly is a fork, not just of the codebase but of the community, which one gets to keep the name? no again. vetoed code never makes it into a release. what you are describing is a pathological situation. solutions to it include the majority 'routing around' by forking a revolutionary branch and taking the name with it, and executive decision by some authority (for which there are currently no guidelines). Pathological? It happens. More frequently than you might expect. I'll be more than glad to share specifics, but some people seem squeamish about discussing such things in public. again, pathological. if things get to this point, the pmc/chair should take corrective/punitive action. commit access is a privilege, not a right; such behaviour as you describe is an abuse of that privilege. Forks happen. Two people with different visions, neither provably wrong, wishing to explore the consequences of a given set of design choices. Generally what occurs is one dies of natural causes. In other cases, a merge occurs as the ultimately it becomes possible to objectively determine if some of the promised benefits are fact or fantasy. - Sam Ruby
Re: DOH! Re: Rules for Revolutionaries
Actually, I quite enjoyed the reply :-). And the cautions you raise are definitely relevant. Well I meant every word of it I just meant to state it...differently ;-) You can over-engineer anything, including a community. But you can also under-engineer, and I get the impression that's sort of where we are right now. The way you describe it sounds like this parable that was told at my kid's cubscout meeting. Where everyone was having fun and doing cubscout things... then the trust was gone and all these strict rules were given and no one shared or helped each other and etc etc... till one day someone just started doing the old things again and it affected everyone and soon everyone was sharing and doing cubscout things. Coming from a corporate background, trust me. Engineering communities doesn't work. Nor does regulation, and beurocracy. I promise to drive this point to death ;-) Next year if anyone is interested in camping in the middle of the Dorton Arena in Raleigh, you're invited -- its quite a touching speech. Theoretically our tent sleeps 6. -Andy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DOH! Re: Rules for Revolutionaries
Often the uncensored version requires a dictionary and a book called Why we say it at hand to get the undertones and coloquialisms. ;-) http://www.m-w.com http://www.amazon.com/exec/obidos/tg/detail/-/1555210104/qid=1036809530/sr=8-4/ref=sr_8_4/102-8855271-2563317?v=glances=booksn=507846 James Taylor wrote: The scary part is that all of us who have been flamed by Andy now need to wonder what the first version of those messages looked like! Yikes! grin -- jt On Fri, 2002-11-08 at 20:03, Andrew C. Oliver wrote: Well this makes my second mail faux pax this week. I actually didn't mean to send this. I sometimes type a mail and then discard it or send it to my self.. U/F in mozilla mail (which I'm not accustomed to) send is right below the file menu and I missed. (new laptop). My sincere appologies to Craig and the rest of y'all. I meant to send a way less snide/sarcastic version of this... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries
I keep wondering why you keep bringing up Duncan's Whoa Bessie... mail. I mean this one: http://marc.theaimsgroup.com/?l=ant-devm=97712718421034w=2 Is it just for historical purposes? Is it because Duncan expresses interesting ideas with eloquence? Sure, Duncan may have been wrong in the Ant context but that should not discredit his ideas altogether. The liberal ideas expressed by Stefano, Sam and to some extent Costin are very inspiring and definitely please a wider audience than Duncan's ideas defending the actions of a selfish pig as he puts hit. (No, I don't think that Duncan is a selfish pig and you shouldn't either.) However, liberal ideologies are just that, ideologies. While Duncan's theory of benevolent dictators might not find favor in the eyes of this public, we should not discard it as being contrary to the Apache way. We should instead recognize it as being a legitimate way of development. It may even be the dominant way of development at Apache under disguise. In addition, it is much easier to stand up and talk about the interest of the community than the interests of individuals less you come off as supporting selfish pigs or being a selfish pig yourself. On a wider scale, it was very hard for the West to fight Communism because the communist ideology sells much better to the unprivileged. Yet 75 years later, the West won, not because of its persuasiveness but because it had much more to show on the store shelves than the communists. Communism is a great idea but it doesn't work. Capitalism is hard to sell but it ends up having better results on the long run. Coming back to Jakarta, I am not suggesting that anyone is at fault. All I am suggesting is that we to stop trashing the work achieved by individuals acting as clear leaders. Leadership is not bad per se. I may be stating the obvious here. So be it. At 11:01 07.11.2002 -0500, Sam Ruby wrote: I differ with that rendition, and believe that it is harmful to the community for it to be propogated. Duncan rejoined Ant and was immediately accepted as a committer. He started work on an internal fork named AntEater. This went on for a short while, until another fork came along named AntFarm. At that point, Duncan said Whoa Bessie and started to put forward a case that he had a unique right to determine what codebase bore the Ant name. This lead up to a PMC meeeting with Brian and Roy in attendance where it was affirmed that the name of a project went with the expressed wishes of a majority of commmitters to that project. This has been the policy that we have followed in Jakarta ever since. References: http://marc.theaimsgroup.com/?l=ant-devm=97712718421034w=2 http://marc.theaimsgroup.com/?t=97712745500023r=1w=2 http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html - Sam Ruby P.S. It is my understanding that what is now Apache HTTPD 2.0 is also the result of a number of forks, one of which ultimately emerged as being the one accepted by the community. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793
Re: Rules for Revolutionaries
Leadership is best achieved and recognized through informal means. Stefano often exerts quite a bit of leadership over Cocoon because the committers respect him. Creating formal owners is a great way to fork a community, but it fails as a social experiment. Certain members in a community through merit, skill and tact (I obviously am generally difficient in the latter) will be heard more loudly than others. Creating ownership or annointing code leaders is frowned upon by even some of today's more formal software methodologies. Everything is everyone's responsibility. I think guarding and guiding the door to committership on a project until the person demonstrates cohesion to the group is a more effective method. As evidence that the control idea doesn't work, please look at the state of modern software developent within most Corporations. It sucks. Linus, etc exhert a lot less control than you think. -Andy Ceki Gülcü wrote: I keep wondering why you keep bringing up Duncan's Whoa Bessie... mail. I mean this one: http://marc.theaimsgroup.com/?l=ant-devm=97712718421034w=2 Is it just for historical purposes? Is it because Duncan expresses interesting ideas with eloquence? Sure, Duncan may have been wrong in the Ant context but that should not discredit his ideas altogether. The liberal ideas expressed by Stefano, Sam and to some extent Costin are very inspiring and definitely please a wider audience than Duncan's ideas defending the actions of a selfish pig as he puts hit. (No, I don't think that Duncan is a selfish pig and you shouldn't either.) However, liberal ideologies are just that, ideologies. While Duncan's theory of benevolent dictators might not find favor in the eyes of this public, we should not discard it as being contrary to the Apache way. We should instead recognize it as being a legitimate way of development. It may even be the dominant way of development at Apache under disguise. In addition, it is much easier to stand up and talk about the interest of the community than the interests of individuals less you come off as supporting selfish pigs or being a selfish pig yourself. On a wider scale, it was very hard for the West to fight Communism because the communist ideology sells much better to the unprivileged. Yet 75 years later, the West won, not because of its persuasiveness but because it had much more to show on the store shelves than the communists. Communism is a great idea but it doesn't work. Capitalism is hard to sell but it ends up having better results on the long run. Coming back to Jakarta, I am not suggesting that anyone is at fault. All I am suggesting is that we to stop trashing the work achieved by individuals acting as clear leaders. Leadership is not bad per se. I may be stating the obvious here. So be it. At 11:01 07.11.2002 -0500, Sam Ruby wrote: I differ with that rendition, and believe that it is harmful to the community for it to be propogated. Duncan rejoined Ant and was immediately accepted as a committer. He started work on an internal fork named AntEater. This went on for a short while, until another fork came along named AntFarm. At that point, Duncan said Whoa Bessie and started to put forward a case that he had a unique right to determine what codebase bore the Ant name. This lead up to a PMC meeeting with Brian and Roy in attendance where it was affirmed that the name of a project went with the expressed wishes of a majority of commmitters to that project. This has been the policy that we have followed in Jakarta ever since. References: http://marc.theaimsgroup.com/?l=ant-devm=97712718421034w=2 http://marc.theaimsgroup.com/?t=97712745500023r=1w=2 http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html - Sam Ruby P.S. It is my understanding that what is now Apache HTTPD 2.0 is also the result of a number of forks, one of which ultimately emerged as being the one accepted by the community. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DOH! Re: Rules for Revolutionaries
Craig wrote: You can over-engineer anything, including a community. But you can also under-engineer, and I get the impression that's sort of where we are right now. I get the impression that, although many of us feel as if our community is indeed under engineered that infact the feeling is caused by inadequate communication amongst ourselves. Particularly the tangetial, off-topic and good old gossip that we would get without effort if we were in a shared physical location. It seems to me that in many ways we simply need a forum (this one) to air our gripes and wishes and see what the reaction is. Prrof it seems is that the incubator project and this list were set up, as far as I can see, simply because the people who thought they were good ideas got positive feedback from the rest of us, and they are more like organic expressions of the community's view of itself than engineered solutions. The problem with anything else is, as Andy pointed out, enforcement. d.
Re: Rules for Revolutionaries
In my personal opinion they are just redundant :-) The rule that matter is that the community control the code and the name - a majority vote in the community can decide ultimately what happens. This is a particular case ( again IMO ) of the releases are majority votes and can't be vetoed. A side effect of the 'revolution' rules is that a veto can be overriden - nobody can veto a revolution ( or a release ), and if you change the entire code base or a part of it you obviously can make changes that were vetoed. There are few important consequences: 1. No person ( or group ) can control a codebase by using veto. It is quite easy to find technical reasons against anything. 2. It removes some personal conflicts. A veto or someone blocking an idea can be painful. It's a big difference between a majority voting against a particular idea and one person vetoing it. 3. To take tomcat as an example - it allows diverging groups or opinions to find the common ground. And that's the really great part IMO. 4. Some good ideas that may otherwise be rejected can eventually live. Costin On Fri, 2002-11-08 at 13:50, Sam Ruby wrote: Rodent of Unusual Size wrote: my curiousity has been set off again. there have been numerous mentions of the revolution concept as used in jakarta, and its widespread acceptance as policy. however, i don't see it mentioned in the jakarta guidelines; in fact, only in ted's proposal for new guidelines. is jakarta's semi-formal acceptance of it as an operating principle actually recorded anywhere, or is it actually just an 'everybody knows that' informal general acceptance? general acceptance is probably too strong a word. There are some, including apparently the original author, who now have doubts. But there can be no doubt that this document has strongly influenced the evolution of a number of Jakarta projects. For further reading, I'd recommend taking a look at topics 3 and 4 in http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html In my mind, the concepts of vetoes, revolutions, and releases being a majority decision are linked. Note: when Roy made the statement about releases, it sure sounded to me like he was stating it as if it were ASF policy. In any case, I would recommend that it be so. Taken together, provisions are made for individuals to get attention to be focused on issues that they feel are important, individuals or even small groups can flesh out concepts that may initially be controversial, and a safety valve is provided so that forward progress can still be made. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
