2012/6/4 Filip Hanik (mailing lists) <devli...@hanik.com>:
>
> 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.
>
There were two fixes in r1345848:
1. Filip, I have nothing against your code style of missing '{' for a
simple statement after an if, but in this case it was worsened by the
fact that the "else" branch was not indented at all. It is rather
confusing.
That is why I had to fix it.
2. The same with NamingResources change.
Both changes are to facilitate further code review. Code formatting
can be different, but it should not be confusing. This commit was to
eliminate confusion, not to make it pretty.
If you approach to regressions is to review diffs (if I understand you
correctly), then mine is to review current code. Confusing code does
not help it.
Reviewing commits and fixing minor issues is normal practice. With 6.0
I usually address them in my vote, so the final commit is clearer, but
the overall change is the same. Your issue is not with code
formatting.
>
> Let me give an example, in my job, I primarily work in support. In the last
> two weeks we've had some serious production regressions on v7, and tracing it
> down was a lot harder than it usually is as the v7 branch still is fairly
> volatile in development, even though we're already at 7.0.27.
In my view, the only way to reliably prevent regressions is to write
more tests, and to test regularly in CI manner.
If it were possible to write an automated test for your issue (I do
not know how hard to reproduce the problem was), there exists such
tool as bisect ("svn-bisect") that allows you to locate "bad" revision
in several iterations.
> 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.
As an example:
Should we abstain from porting "infinite timeouts support" to 7.0? It
seems a bit risky (I do not know connectors so good to review it
properly), but it is important for those experimenting with new web
socket api.
Should we postpone web sockets for a year (saying that current support
is broken, or is limited to some specific connector)? It will
prevent ones from testing and evaluating the feature, and we might
well lose a year- without proper testing of the feature.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
