tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik \(mailing lists\)" <>
Subject RE: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/deploy/ java/org/apache/tomcat/util/net/
Date Mon, 04 Jun 2012 19:32:15 GMT

> -----Original Message-----
> From: Mark Thomas []
> Sent: Monday, June 04, 2012 12:41 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r1345848 - in /tomcat/tc7.0.x/trunk: ./
> java/org/apache/catalina/deploy/
> java/org/apache/tomcat/util/net/
> On 04/06/2012 17:05, Filip Hanik (mailing lists) wrote:
> >
> > Ok, this is back to code discipline. At some point, we'd have to
> > expect that more users will adopt v7 in production (I'm still seeing
> > 80%+ being on v6), at that point, commits like this do nothing except
> > pollute the diffs.
> It depends which diffs you are looking at. If you are checking trunk
> against 7.0.x to check that the back-port of a fix hasn't been missed
> then having trunk and 7.0.x as closely aligned as possible is helpful.
> If you are checking the changes in 7.0.x then formatting changes don't
> help. It all depends on your point of view. I would also add that
> consistently formatted code is easier to read and less likely to be
> misread.
[Filip Hanik] 
That's my point exactly. I believe we did a great job with stabilizing Apache Tomcat 6, and
keeping it stable. I don't think we are doing as good of a job with Apache Tomcat 7. I think
we can do better.
So it's really what is the goal, if the goal to back port patches from trunk, then sure. Format
both branches. That goal however has a flaw, it doesn't treat 7.0.x as a production grade
branch, but a development branch.

> > Servlet 3.1 has released a draft, where I'd expect that trunk is
> > headed. There is no reason for v7 to continue to be an exact mirror
> > of trunk, especially from a formatting point of view.
> That work hasn't started in Tomcat yet so at the moment there is no
> driver for them to diverge. That will probably change over the next few
> months.
[Filip Hanik] 
Should change fairly shortly since the draft is out.

> > While this makes the code prettier, it makes it a lot harder to trace
> > regressions.
> Not just prettier (see above) but I agree regarding regressions.
> > I'd suggest we start treating this as a stable branch, stable in my
> > perception is that it's a branch that I use to support production
> > environments, and that I can use to trace regressions and fixes.
> The obvious change would be to move 7.0.x to RTC rather than CTR. That
> inevitably slows down the pace of development. We as a community need to
> decide if that is what we want to do. If you want to propose that, I
> suggest you start a new thread on that specific topic.
[Filip Hanik] 
Doesn't have to be one extreme to another. All it takes a bit more discipline and an aligned
goal with the 7.0.x branch.


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

View raw message