2010/7/12 Marc Guillemot <mguille...@yahoo.fr>: > >> 2. There is NO consensus on @Version format. >> (...) > > if there is no consensus, then all commits concerning this should never have > occurred ;-)
The consensus is that $Date$ is broken and must not be used. Nothing else. > > Why a 80 characters limit? Is this a recognized style rule for Tomcat? > It is part of the default code formatting configuration in the IDE that most committers are using. The issue was that the keyword broke. Rather than fixing just the issue at hand, I went further to prevent it in the future in that particular file by using a shorter keyword. > > If the build doesn't ensure that, there > is no guaranty that tabs won't be introduced again in the future and > therefore fixing them now is nearly lost time. > Nearly all committed code is reviewed, and such issues are spotted promptly. Actually, I do not bother whether there are tabs somewhere. I will be bothered only if I will start editing the affected file, or will prepare / apply a patch. In that case we have agreed that such files can be converted to spaces by CTR. >> 5. Is there experience whether checkstyle checks run fast, or there >> are noticeable delays? >> >> The "Re: r960104" thread was about preventing commits that have wrong >> whitespace. It probably means that checkstyle is run automatically >> by IDE, or by the buildbot. Do others have positive experience with >> such configurations? > > checkstyle is fast (in fact it doesn't really matter for the build) > Plugins for the IDE are really nice as they highlight the problems and need > only to run on modified files. Good to know. >> I do not mind against checks that already succeed for the existing >> code. Though if they always succeed they are not really useful. > > wrong. Let's take IllegalImport as an example. It checks that some imports > (default to sun.* packages) are not used. It currently pass but one error > from one committer is enough to make them fail (and don't say that it can't > occur ;-)). > There are other ways to ensure that. I use "Execution environment" as the selected JRE in Eclipse, and that prevents such imports. (sun.* packages are excluded, because they are not part of the public API). > > I'm impressed by the resistance of Tomcat committers against changes that > aim to improve the code quality. I do not resist. I just think that it is a bit of a waste of my time. If somebody else wants to spend time on this, I can encourage that person. > The current discussion remembers > me this patch: > "Run the unit tests as part of the build!!!" > (https://issues.apache.org/bugzilla/show_bug.cgi?id=47124) And the tests are not run as part of the default build. They are run when doing a release and they are run by buildbot. > I know, but it is a desperate step. I have tried following approaches: > - provide patches ready to apply -> failed I appreciate the patch, but it touches project policy and that needs a support on d...@. > - start discussion about usage of recognized methods to improve code quality > -> not really a success Really? I thought it was a success. > - try to be ironical (...) > -> according to your comment, it seems that it fails as well Please see "How it works", esp. "Project Management" and "Decision Making" http://www.apache.org/foundation/how-it-works.html Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
