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

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

rubys@us.ibm.com wrote:
> 
> >So why not start fresh with Tomcat.next on a separate branch, reusing
> >as much as possible from the existing code base? When you copy code to
> >use in a new version like this, you tend to clean it up at the same time
> >and add comments. I have the same feeling as Craig that this approach
> >will take us to the goal a lot faster.
> 
> Speaking only for myself, I've invested considerable amount of time into
> making sure that Jakarta works on Windows, JDK 1.1.X, and integrating in
> patches which makes Jakarta work on Irix, EBCDIC machines, etc.  I've also
> seen considerable bug fixes and even a stray performance enhancement or two
> get integrated - most of which are not architectural changes or even design
> changes, but simple coding fixes.  I don't see this work as being done, but
> ongoing.  None are these changes are significant in themselves, but the sum
> total would be difficult to merge - inevitably resulting in lost changes
> and more work.
> 
> Now I am contemplating servlet reloading.  With the current architecture, I
> would have likely made this code integral to Tomcat, but for performance
> reasons would have made it optional.  Now I'm contemplating making it
> plugabble instead.  However, if tomcat.next were on a separate branch, and
> was not being implemented in a way that ensured that there was always a
> working system to deal with, then I would most likely wait.
> 
> This is what concerns me most.  Knowing that there is a separate branch
> would have a chilling effect on all other development.  Why fix a bug on
> the current base when there is a new one only a few months away?
> 
> This is not simply one sided.  By working on the same branch, there will be
> more eyes reviewing the code, making fixes, or at least identifying issues.
> For example, at the moment there is a regression in the watchdog servlet
> tests that I have observed on both Win32/JDK1.1.8, and Linux/JDK1.2.
> Whether it was directly tomcat.next changes or some subtle combinations of
> changes, this regression was a surprise.  One thing I do know is that such
> issues are easier to track down knowing precisely when the regression was
> introduced.
> 
> The only thing that would concern me more than the issues I described above
> is if one or more people with significant value to contribute felt that
> that cost of working together as a team was not worth it, and therefore
> decided not to participate.

Very well said. I agree 100% with Sam on this.

Some of us like the incremental approach and some of us like the "branch
and merge" approach. Myself, I'm an old believer of the "branch and
merge" who understood that it simply doesn't work, or, if it does, it
requires much more work to be done, due to the fact that you are aiming
to a moving target.

But I totally understand how some of you guys feel: when people wiser
than me told the exact same words I didn't follow them. I was not able
to see the problem.

Now I am, but I can only show you the problems that _might_ come (with
Sam's words above).

Anyway, we are here to learn and open source dynamics are stronger than
any mistake we can make. True, it could create friction, slow down the
process and waste some double efforts, but learning is a painful and
expensive process.

So, again, I'm totally with Sam: I'd like the project to follow an
evolutionary path, but since I'm not the one that is going to work on
that code, who am I to decide?

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