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 at the same time, pissed many people off (myself included)
and created a lot of problems in the users.
I'm not sure about this. I've noticed that for a long time people unfamiliar with the details were thinking of 3.3 as the production version, and of 4.0.x as the development version. People had a choice of what to use, and I think this is always a good thing to have.
The rules for revolutionaries had a bug since they didn't specify what was going
to happen to the project that was overruled by the revolution.
We have to fix this in the future.
But the way I want this to be fixed is to avoid the fragmentation of a project
identity and Tomcat did exactly that.
How do you feel about this?
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.
Cheers, Ovidiu
-- Ovidiu Predescu <[EMAIL PROTECTED]> http://webweavertech.com/ovidiu/weblog/
