I think it is a good idea to have a production branch and developement
branches. When a feature is stable, then it can be merged to production
branch.
When we decided to upgrade to the latest grizzly framework. I couldn't get
the code to compile, so I have to go back to some revisions back.
thanks,
Fay
On 8/21/07, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>