tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <henri.go...@gmail.com>
Subject Re: Review model take 2
Date Fri, 21 Sep 2007 06:16:00 GMT
So what about RTC for core and CTR for extensions in incubator land ?

2007/9/21, Costin Manolache <costin@gmail.com>:
> I have a strong feeling this is turning again into a debate over words,
> arcane details
> and abstract concepts ( 'what is a trunk' and how to increase innovation )
>
> The real issue is quite simple, and not having a trunk or all the new
> process seems
> more like an attempt to solve it:
>
> We want tomcat evolution to be done by consensus or at least majority, not
> by one
> individual ( be it Remy or Filip or anyone else ) making decisions and
> changes to the core API without
> consultation and agreement from others ( and yes, most vetoes are probably
> invalid and
> bad - the changes are technically ok, and the veto is a blunt tool to
> express lack of consensus
> and frustration ).
>
> The whole veto / remove trunk / personal hurt feelings / CTR / RTC / process
> debate
> is just a way to avoid this from happening.
>
> Yes, we want innovation and change and contributions and all that - but that
> doesn't mean
> that anyone who can make a technically valid change ( i.e. where a veto
> would be invalid )
> should make it - if it affects other people and it lacks consensus.
>
> That doesn't mean you can't add features ( to 6.0 or trunk or however you
> want to call it ), or you
> can't make big changes, or someone can block 'progress' or impose his own
> vision of progress.
> All those proposals evolve around how to involve more people in decision
> making and be as close
> to consensus as possible.
>
> I personally consider tomcat way overbloated - so I think I'm on the same
> side with Remy on voting against
> adding any new feature that could be done as a plugin, and I would be happy
> to see 'innovations'
> in tomcat removed from std and moved to separate plugins, until we're at the
> same size with jetty
> or other containers in the base distro. But I do understand Filip's
> frustration and the desire to try now
> things - and this should happen, not in sandbox but in 6.0  tree, except not
> in the core and with
> controlled API changes.
>
>
> Costin
>
> On 9/20/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> >
> > Will f/w board since this follows from the 'no more trunk' comment which
> > some officers questioned.  Please don't cc per-say, but feel free to f/w
> > a relevant response to board@a.o (it's bad form to crosspost a message
> > with both public-and-private destinations).
> >
> > Bill Barker wrote:
> > > "William A. Rowe, Jr." <wrowe@rowe-clan.net> wrote in message
> > >>
> > >> All that said, the topic of "no more trunk" came up at the board
> > meeting
> > >> today.  I gave a very brief background and suggested that some of the
> > >> renewed interest by folks who had been silent throughout the Filip-Remy
> > >> trunk war is a hopeful sign; with renewed interest the project is very
> > >> likely to be able to manage itself successfully through these personal
> > >> and stylistic disagreements; the board is satisfied to see the project
> > >> try to work out these issues themselves as long as development once
> > again
> > >> is encouraged.
> > >
> > > TC 4.1.x and TC 5.5.x represented major changes to the core API, and
> > > resulted in much more stable Tomcat code.  There is no such issue for TC
> > > 6.0.x (just a disagreement on the comet API, which we have already dealt
> > > with, and decided to let software-darwinism take it's course).  Thus,
> > there
> > > is really no reason for a "trunk" at this time, at least until the
> > Servlet
> > > 3.0 spec comes out.  If somebody wanted to make a [PROPOSAL] for major
> > > changes to the core TC 6.0.x API, then I can see setting up a "trunk"
> > again.
> > > But there is no such animal lurking at this time.
> >
> > No doubt, these were significant departures from their previous code.
> >
> > But, are you suggesting that there is no need for trunk until there is an
> > idea you happen to champion?  Present you with an idea that you like and
> > half the committee might decide to permit new development again?
> >
> > This is certainly turning the idea of "show me the code" on it's head.
> >
> > To give an example oft cited on this list, httpd maintains a trunk.  It
> > might be released some day as-is, it might never be released.  But it's
> > a staging ground to prove up an idea before injecting that idea into the
> > shipping stable version.  It appears there is no such wilderness at
> > Tomcat.
> >
> > Sandboxes don't cut it.  It's very clear sandboxes are one-man-shows at
> > Tomcat.  As such, they go against the concept of collaborative development
> > and don't belong at the foundation.  If I misunderstand, and sandboxes are
> > shared spaces for proving concept-not-the-programmer, and everyone is
> > welcome at each sandbox to improve the proof of concept themselves, then
> > my objection is unfounded.
> >
> > It seems the list wants very tight control on the stable 6.0 branch, so
> > your observation that trunk is irrelevant hasn't jived since I first read
> > this post (and I considered it's implications for a good 12 hrs).
> >
> > It also brings up a real question of why was it so important to 'kill
> > trunk' if trunk, admittedly, is not relevant?
> >
> > >> But without reestablishing a method for the committers to innovate, or
> > >> with continued/renewed territorial behaviors, this issue will likely
> > >> be noticed again by the board a few months from now as an issue in need
> > >> of a solution.
> > >
> > > I maintain that there is currently a very small barrier to "innovating"
> > on
> > > Tomcat.  We had one innovation that was shown to have a big whopping
> > > security hole in it, so it was withdrawn until a better patch can be
> > made
> > > (i.e. the system worked).  There were people (myself included) that
> > would
> > > have preferred a modular patch (e.g. with httpd, I can configure it so
> > that
> > > mod_alias isn't included with a few small edits, but the patch in
> > question
> > > didn't allow for that, which was the complaints).
> >
> > You are talking about one patch.  Has Tomcat become so pathetic that
> > there's
> > only one example of innovation in the past /x/ months to hold up as the
> > one
> > true example?
> >
> > Let's hope the rule systems that Tomcat debates and settles on reflect the
> > diversity of contributions, as opposed to a small handful of exceptions.
> > The fact that the rule systems themselves are being debated points me to
> > really wonder if there is any code debate here at all, or nothing more
> > than
> > a clash of personalities which "changing the rules" is the simplest
> > solution
> > to getting one's way?
> >
> > In any case, the list continues to ponder what the meaning of the
> > branches,
> > sandboxes etc all are, and I'll step out of this conversation (baring any
> > truly insane proposals) while the TC core community comes to terms with
> > how
> > Tomcat can still prosper, and lose the perception of being a fiefdom of
> > the
> > chosen few.
> >
> > Bill
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message