I don't have the error any more. It was failing on some junit test.
On 8/22/07, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:
>
>
>
> 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>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>