Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

[Hans Bergsten <ha...@gefionsoftware.com>]

"Anil K. Vijendran" wrote:
> 
> On Sun, 9 Jan 2000, Hans Bergsten wrote:
> 
> > discussion dealt with a lot of other stuff as well, but I saw at least some
> > support for parallel development; make sure all cleanup of Tomcat 3.x is
> > done in line with the Tomcat.next proposal, at the same time work from
> > scratch with Tomcat.next and refactor in as much as possible from both
> > Tomcat and JServ.
> 
> What would the point of doing two parallel pieces of work be? As I see it,
> we either relegate the current branch to bugfix mode and start new work by
> creating a fresh workspace and pulling in code as necessary, OR keep the
> current branch, flush out junk and incorporate Craig's ideas in there.
> 
> Doing both would be a waste of resources that we have here. I can see some
> people moving over to work on the new branch and some others sticking with
> the older branch. Also keeping two parallel tracks open causes confusion
> on where we implement the next version of the specifications.
> 
> Either we decide to flush out Tomcat.current or we decide to dump
> Tomcat.current, leave it in bugfix mode and move on to Tomcat.next which
> will pull in code from Tomcat.current as necessary.
> 
> Having said that, my vote would still be to see how the cleanup is
> done. Evaluate the possibility of moving over to a fresh branch after much
> of the "cleanup" on Tomcat.current is done.

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.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

["Zacharias J. Beckman" <zb...@creativesun.com>]

> 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

I agree.

I'm fairly new to Jakarta. Having seen parts of the project, it's intimidating;
there's no doubt in my mind that a more clean code base (particularly one that is
well documented) is going to engender hordes of new developers jumping on board
(ok, I'm being a bit enthusiastic--but it will at least help to get me involved).

There are some areas I would very much like to tackle in Jakarta. CSI is developing
software that requires very, very robust, very flexible server solutions--things
like load balancing, better Apache integration, installation/deployment tools,
admin tools, and even plain old documentation are all areas that I could easily see
myself contributing. But doing so on the current code base is so intimidating I
doubt it's going to happen. There too much history and, unfortunately, I don't have
the time available to come up to speed on it. Besides, there's nothing more painful
than figuring out someone else's undocumented code...

While I hate to do anything that would delay the next feature set, I'm more loathe
to choose a path that might result in lower quality code. Given the choice, I'd
choose a better server a little bit futher out...

So my fractional vote would be to go ahead with Tomcat.next.
--
Zacharias J. Beckman - zbeckman@creativesun.com - (U.S.) 305-281-8701
Creative Sun Inc., Publishing for the Internet - http://www.creativesun.com

Far better it is to dare mighty things, to win glorious triumphs, even
though checkered by failure, than to take rank with those poor spirits who
neither enjoy nor suffer much, because they live in the gray twilight that
knows neither victory nor defeat. -- Theodore Roosevelt

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

[co...@costin.dnt.ro]

> As I suspect most of you are aware, a very famous open source project
> uses this sort of dual branch scheme: development/stable (with only
> bugfixes being committed to the stable branch).

But the "development" branch is not realized by throwing away the stable
one and starting from zero.

Tomcat works in the same mode - 3.0 is the stable code/branch, we are
developing in the main branch - whenever we feel the code is stable 
enough we create a new stable branch.

Costin

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

[ja...@almery.com]

Anil K. Vijendran writes:

 > I see this as unnecessary and bad. Forcing people to choose between
 > Tomcat.Next and Tomcat.Current to work on seems unfair.

As I suspect most of you are aware, a very famous open source project
uses this sort of dual branch scheme: development/stable (with only
bugfixes being committed to the stable branch).

It works for them, but they have a few more people on the project,
which may be the critical differentiator in this case.

Cheers,
-- 
Jay Doane | doane@acm.org

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

[Hans Bergsten <ha...@gefionsoftware.com>]

"Anil K. Vijendran" wrote:
> [...]
> 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?

My vote would be yes. We need to take care of the short term things, listed in 
the 3.1 plan, within a reasonable time frame. The best way to do this is to use the 
current code base. But that doesn't mean we can't start looking at the future in 
parallel (see more below).

> 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?

This is not an either or in my mind. The things listed in the 3.1 plan are
pretty minor adjustments. Do them based on the current code base.
  
I'm thinking about what we do after the next release. Things discussed for the 
future requires a lot more work; things like load balancing, support for 
different configurations (stand-alone, embedded, add-on, etc.), configurable 
session persistence, administration functions (e.g. being able to start/stop 
contexts individually), etc.
  
Tomcat.current was not designed with these goals in mind. What will it take
to make it feasible for someone outside the original design team to help out 
with the development of these major features? How much must the architecture
be changed? We need documentation, cleaned up and commented code to answer
these questions. No one seems to have the time to do this now, so it looks
like after the release of 3.1, we'll have to wait for someone to document the
current architecture, analyze what must be done, and then we can start adding
the big stuff. How long will that take?

If we instead start with Tomat.next now, with an architecture based on the
current requirements, we will have a great understanding of what kind of
architecture it takes to fulfill the goals. This can help us compare the
efforts of continuing development based on Tomcat.next or Tomcat.current.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next ServletContainer

[James Todd <jw...@pacbell.net>]

i personally don't see a problem with two paths as long as folks
communicate bi-directionally. if done correctly the momentum
on both paths will greatly improve (my hunch) the stability/docs/etc
will come into being as well as new innovative tools and techniques
which layer in, on and around the core.

again, i've worked on several projects (before jswdk/tomcat)
where we *had* to do this. eXtreme programming at it's best.

- james <refusing to see a half-empty glass/> todd

"Anil K. Vijendran" wrote:

> 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
> > Tomcat.next 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 Tomcat.next 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 Tomcat.next.
>
> 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         hans@gefionsoftware.com
> > Gefion Software               http://www.gefionsoftware.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
>
> --
> Peace, Anil +<:-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

["Anil K. Vijendran" <An...@eng.sun.com>]

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 
> Tomcat.next 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 Tomcat.next 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 Tomcat.next.

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		hans@gefionsoftware.com
> Gefion Software		http://www.gefionsoftware.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 

--
Peace, Anil +<:-)

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

[Hans Bergsten <ha...@gefionsoftware.com>]

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. 

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 
Tomcat.next doesn't turn out as we like, drop it, otherwise drop Tomcat.current).

And of course, while work is being done on the Tomcat.next 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 Tomcat.next.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

[Stefano Mazzocchi <st...@apache.org>]

Hans Bergsten wrote:
> 
> "Anil K. Vijendran" wrote:
> >
> > On Sun, 9 Jan 2000, Hans Bergsten wrote:
> >
> > > discussion dealt with a lot of other stuff as well, but I saw at least some
> > > support for parallel development; make sure all cleanup of Tomcat 3.x is
> > > done in line with the Tomcat.next proposal, at the same time work from
> > > scratch with Tomcat.next and refactor in as much as possible from both
> > > Tomcat and JServ.
> >
> > What would the point of doing two parallel pieces of work be? As I see it,
> > we either relegate the current branch to bugfix mode and start new work by
> > creating a fresh workspace and pulling in code as necessary, OR keep the
> > current branch, flush out junk and incorporate Craig's ideas in there.
> >
> > Doing both would be a waste of resources that we have here. I can see some
> > people moving over to work on the new branch and some others sticking with
> > the older branch. Also keeping two parallel tracks open causes confusion
> > on where we implement the next version of the specifications.
> >
> > Either we decide to flush out Tomcat.current or we decide to dump
> > Tomcat.current, leave it in bugfix mode and move on to Tomcat.next which
> > will pull in code from Tomcat.current as necessary.
> >
> > Having said that, my vote would still be to see how the cleanup is
> > done. Evaluate the possibility of moving over to a fresh branch after much
> > of the "cleanup" on Tomcat.current is done.
> 
> 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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------