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:
Please, let me ask you a few questions. I would be very happy if you or
others could answer them:
1) was Catalina voted as Tomcat 4.0 explicitly by the majority of the
tomcat dev community?
True.
2) did the above vote take place when Tomcat was at 3.2 version?
True.
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.
4) is it true that at some point and for a while two different set of
committers were working on two different tomcat codebases and both
released as *tomcat* because of technical divergences?
That's also true. A lot of code was shared between the 2 codebases
( same jasper, ajp connector ) and a lot of ideas were common.
Yes, I recognize that but it's fairly obvious: they were doing the exact
same thing!
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.
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.
It would have solved *much* of the negative feelings that the tomcat community
was spreading around the ASF at that time.
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.
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.
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?
+1
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
