tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anil K. Vijendran" <>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Tue, 11 Jan 2000 22:12:57 GMT
On Tue, 11 Jan 2000, Hans Bergsten wrote:

> Stefano Mazzocchi wrote:
> > 
> > Hans Bergsten wrote:
> > > I believe I touched on all of this in my reply to Sam. Just a comment about
> > > resources. I'm brought up in the corporate world, where "brain power" is
> > > a resource limited by budgets and the ability to hire more people. I'm new
> > > to the Open Source world, but I see one of the big advantages being pretty
> > > much unlimited resources! As long as there's challenging work to be done,
> > > and people get the feeling they are really contributing, you have a world
> > > full of developers eager to jump in.
> > >
> > > We have already added a number of committers since we started Jakarta, and
> > > there are other potential committers submitting patches on a daily basis.
> > > If we make it possible for people to contribute with larger things than
> > > pure bug fixes, like brand new features, I'm sure you will find a lot of
> > > people joining the project. But as I have mentioned in other mails, it's
> > > very hard to do something "big" unless the code base is clean and
> > > understandable. So yes, if starting a new branch means the current branch
> > > gets relegated to bugfix mode, so be it. We don't have to explicitly decide
> > > that it should be like that; it will take care of itself.
> > 
> > You fail to consider that forking friction develops in this case and you
> > get "unlimited human resources" only when you are the only project in
> > town. Otherwise you have "half unlimited resources", or even less than
> > that since much more time is spent dealing "my project is better than
> > yours" and such (KDE vs. GNOME, for example).
> > 
> > Open source dynamics are strange beasts.
> I admit I'm new to Open Source, and that "unlimited resources" of course
> was an exaggeration. And yes, creating a new branch means active contributions
> will be split between the two branches for a while. 

I see this as unnecessary and bad. Forcing people to choose between
Tomcat.Next and Tomcat.Current to work on seems unfair. The reason some of
us are willing to cleanup Tomcat.Current and document it is so that we can
actually have something that will run at all times and can actually meet
the March release plan. These are people that care about having a release
by March.

> But we're not talking two completely different products (like KDE and GNOME) that 
> will continue to live separate lives for the foreseeable future; these two 
> branches should merge at some time, or one of them should be dropped (if 
> doesn't turn out as we like, drop it, otherwise drop Tomcat.current).

Imagine two Tomcat's that do the exact same thing (servlet/jsp engine +
plugin for Apache) but have different models and relegions internally. 
That wouldn't be a good thing IMO. 

When both are "done" what are the criteria for choosing one from the
other? You think we'll be willing to agree to throw away what we have been
working on seriously? I'm willing to say that Tomcat.Current would be
considerably cleaned up by March. We would end up having two Tomcats with
different internal models. Now who decides which is "better" then? 

> And of course, while work is being done on the branch, short term
> bugfixes and minor feature improvements will have to be done on the Tomcat.current
> branch. Most of this should be possible to copy and reuse in

I don't know... All this looks like hypothesis to me. This seems needless
complication because we don't want to wait and see what the cleaned up
Tomcat 3.1 is going to  look like.

Let me summarize and see if we can actually nail this sucker and not
revisit it again. 

There's the following issues I can see here. 

1. Creating and actively working in parallel on two different code bases.
   Should we do it or not?

2. Tomcat.Current vs Tomcat.Next. Do we believe that having a release in
   March is not so important as having a clean codebase and team together? 

I have a strong -1 on 1. 

Re: 2, My vote is for Tomcat.Current because I believe it can be
cleaned up and documented well enough. It can be used to meet the Tomcat
3.1 release plan. It will keep both classes of developers --
codebase-focused and release-focused -- working on the same thing. 

But I'm willing to go with either Tomcat.Current or Tomcat.Next, as long
as we all work towards a plan (if we pick Tomcat.Next). 

Let us decide now and pick one of the alternatives and stick with it. 

> Hans
> -- 
> Hans Bergsten
> Gefion Software
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Peace, Anil +<:-)

View raw message