tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik \(mailing lists\)" <>
Subject RE: Tomcat 7 code policy (was: Re: svn commit: r1345848)
Date Tue, 05 Jun 2012 13:10:55 GMT

> -----Original Message-----
> From: Konstantin Kolinko []
> Sent: Monday, June 04, 2012 3:50 PM
> To: Tomcat Developers List
> Subject: Re: Tomcat 7 code policy (was: Re: svn commit: r1345848)
> 2012/6/5 Konstantin Kolinko <>:
> >>
> >> For that reason, I'd like us to be more conscious about our commits
> on v7 and start looking at v7 as bug fixes and stabilization as the
> primary drivers for commits.
> >
> > Stabilization usually means that we stop fixing bugs in "stable"
> > version besides easy ones and allow them in trunk only. It is not what
> > I want for 7.0 now.
> >
> > There is no expected date for Tomcat 8, and if the date is too far
> > (e.g. further than 9 months) it would be too late for most problems
> > that users are reporting.
> >
> What do people think about introducing a STATUS file in 7.0,
> but not yet switching to full RTC policy?
> I mean let the author decide and propose his change for review if he
> deems it is too risky to commit immediately, or is worth reviewing.
> E.g. if
> a) the change is too complex,
> b) touches many components,
> c) touches core pieces of Tomcat.
> I do not think 7.0 will benefit from slow RTC of Tomcat 6,  but there
> are some patches that are worth a review, and having a formal STATUS
> file approach is better that random discussions on dev@.
> One notable benefit of the STATUS file is that the change is proposed
> when it is ready for review.
[Filip Hanik] 

I think the STATUS file is slowly becoming obsolete. If we instead adopted
git, and used features like those available on github where you can create a
merge request, you'd have everything in one place, and nothing was lost.
My only point with the original post was to slow down the zero value commits
in Tomcat 7, as people start to rely on it for production grade, we should
treat it the same. I think it's too early for RTC, but it's too late for
refactoring in that branch too. Balance is the key.


> Best regards,
> Konstantin Kolinko
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message