FYI, there is a little war on the tomcat mailing list about how commit
are handled. This community didn't yet faced such problems (but we never
know). Below is something interesting to read....
-- Jeanfrancois
-------- Original Message --------
Subject: Re: [VOTE] Send trunk to the sandbox
Date: Tue, 21 Aug 2007 14:54:22 -0500
From: William A. Rowe, Jr. <wrowe_at_rowe-clan.net>
Reply-To: Tomcat Developers List <dev_at_tomcat.apache.org>
To: Tomcat Developers List <dev_at_tomcat.apache.org>
References: <20070813181349.791471A981A_at_eris.apache.org>
<fabbh8$2gb$1_at_sea.gmane.org> <46C949E5.10609_at_gmail.com>
Boy, what an absurd thread...
jean-frederic clere wrote:
>
> I would also propose that we take an handling of releases similar to httpd.
> See http://svn.apache.org/repos/asf/httpd/httpd/
I just want to make sure you aren't confusing the above ^^^
with below vvv
> branches contains the productions branches and the experimental
> developpemnt branches.
>
> trunk contains the place where the commmun developement and the new
> agreed features and bugs fixes are going.
> To move something from the "experimental developpement branches" to
> trunk (or to a production branche) we vote it. (in a file named STATUS)
> once accepted (no -1) the stuff enters the production or trunk. If
> someone starts something in trunk and gets a -1 he should create a new
> branche with the new code and propose a vote to get it back in trunk.
This isn't how httpd works. Any committer can commit new features or code
to trunk. Any committer can veto a commit, as well, at which point it has
to leave trunk unless the author can convince the veto'er of their plan,
or they agree to work together to fix the committed code to everyone's
satisfaction. Or (and this is rare) there's no *technical* justification
for the veto, and the rest of the committers agree it isn't valid.
Now on the subject of sandboxes, they don't exist to shove off committers.
They are tools for committers to use to develop their own proof of their
concept. Let's face it, on radical changes, it's almost impossible to
keep the development branch building until the change is complete.
But it's not a purgatory to which you can shove another committers' code
into. They either agree their work needs to be refined, or reverted.
Revert the trunk code on a case by case basis the code that you cannot
agree on, and let the author move it to a sandbox if that is their choice.
That is how the httpd project handles svn.
Any suggestion to "push aside" the current trunk contents shows some
incredibly poor respect for fellow committers and certainly reflects
badly on the state of the community and project.
All of this is to say slow down, agree to back out offending patches from
trunk, and just move forward to 6.5 or 7.0 or whatever it is, IMHO. You
are using SVN to bully each other into agreement, which is worthless if
your goal is to build back up the tomcat community. If you seek to destroy
it, there is really a quicker and more efficient way to go about it.
All of which I point out as simply an observer and user of Tomcat, and from
years of similar debates at httpd. So take this for what it's worth.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tomcat.apache.org
For additional commands, e-mail: dev-help_at_tomcat.apache.org