Fay Zheng wrote:
> 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.
Grr that's not good. Do you have the errors you got?
Thanks
-- Jeanfrancois
>
> thanks,
> Fay
>
>
> On 8/21/07, *Jeanfrancois Arcand* <Jeanfrancois.Arcand_at_sun.com
> <mailto: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
> <mailto:wrowe_at_rowe-clan.net>>
> Reply-To: Tomcat Developers List <dev_at_tomcat.apache.org
> <mailto:dev_at_tomcat.apache.org>>
> To: Tomcat Developers List < dev_at_tomcat.apache.org
> <mailto:dev_at_tomcat.apache.org>>
> References: <20070813181349.791471A981A_at_eris.apache.org
> <mailto:20070813181349.791471A981A_at_eris.apache.org>>
> <fabbh8$2gb$1_at_sea.gmane.org <mailto:fabbh8$2gb$1_at_sea.gmane.org>>
> <46C949E5.10609_at_gmail.com <mailto: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
> <mailto:dev-unsubscribe_at_tomcat.apache.org>
> For additional commands, e-mail: dev-help_at_tomcat.apache.org
> <mailto:dev-help_at_tomcat.apache.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto:dev-help_at_grizzly.dev.java.net>
>
>