"Konstantin Kolinko" <knst.koli...@gmail.com> wrote in message
news:427155181003081100l7078ac60q2704f09f66040...@mail.gmail.com...
I propose to relax our RTC policy and use CTR for the types of changes
listed below:
2010/3/8 Konstantin Kolinko <knst.koli...@gmail.com>:
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
Already decided. No need to vote.
2. I think that we can have C-T-R for any svn metadata (svn:
properties), as those are not the code. I am +1.
Allow C-T-R for changes to svn properties:
[ ] +1
[ ] 0
[X] -1
Same concerns as Mladen
3. I think that we can have C-T-R for any whitespace changes in the
code. These are generally discouraged, but might be necessary to ease
backporting of patches.
Note, that whitespace-only changes
a) can be verified in viewvc when viewing the committed patch in
"Colored Diff" mode. E.g.,
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?r1=896544&r2=896543&pathrev=896544&diff_format=h
b) can be verified by svn diff command:
svn diff -x -w
will generate a patch ignoring all whitespace changes.
Whitespace changes can hinder applying other patches, generated before
them. As for line numbers, e.g. when deciphering stack traces, we can
always look at the SVN tags that we have from the releases.
I am +1 for C-T-R these.
Allow C-T-R for any whitespace changes:
[ ] +1
[X] 0
[ ] -1
Don't really see a use case for this, but can't come up with a reason to
oppose it either
4. Trivial fixes for any English message strings and message constants
in the code. I mean, inaccuracies and misprints. I am +1 for C-T-R
those.
Adding/removing parameters, and changing code that displays these
messages is not a trivial change.
Things to beware here are single quotes and '{}' brackets. If message
string does not have arguments, it is used as is, and those symbols
have no special meaning. If it does have arguments, those symbols
have special meaning. E.g., there will be an exception if there is
'{}' that does not contain a number and is not inside single quotes.
Allow C-T-R for trivial fixes to English messages that are in resource
files
and those that are inline in the code. This includes typos and rephrasing,
but does not include adding/removing message parameters.
Technical issues to beware are mentioned above.
[ ] +1
[X] -0
[ ] -1
Really don't like this one, since it requires more review of commits. But
again, can't find a good reason to vote -1
5. Any fixes for any translations.
I cannot review the textual part of the changes, only the technical
part, and that can be as well done looking at the commit email.
The risks here are not very high, as tomcat-i18n-*.jar files do not
contain any code in them and can be fixed without recompiling.
The technical requirement here is that
all *.properties files should contain only 7-bit characters. All
others should be \uxxxx escaped. The program to perform such
conversion is native2ascii.
For consistency, there should be end-of-line character on the last
line of the file (as native2ascii always adds it).
The specification (JavaDoc for java.util.Properties) says that the
files are technically in ISO-8859-1, but, as was discussed around a
year ago, we should not allow 8-bit characters from the upper part of
ISO-8859-1 charset. The reasons that I remember are:
1). Some IDEs (or IDE plugins) have configuration where by default
they are reading *.properties files not in ISO-8859-1, but in the
system default encoding. Thus, if the file has character from the
upper part of ISO-8859-1, they can be read incorrectly. My own story
of observing this was with the PropertiesEditor Plugin for EclipseIDE
I suppose that using system encoding by default have some meaning.
E.g. when running native2ascii before opening the file in the IDE this
setting will allow to open them correctly.
2). We had some files in ISO-8859-1, some in Windows-1252, some in
UTF-8. There should have been some reason why that happened.
That said, I am +1 for C-T-R for any translation fixes.
Allow C-T-R for any fixes for non-English resource files.
The files must use 7-bit characters only. Other symbols must be
escaped with \u, as does native2ascii.
[X] +1
[ ] 0
[ ] -1
AFAIK, we don't have any committers that speak non-European languages, and
the Japanese users will just laugh at us on the users list if we get it
wrong ;).
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing "C-T-R" or "trivial" in the message?
This is not mandatory, but I would prefer some indication in the
commit message, that it was done using CTR rule. I propose to write
"C-T-R", but I wouldn't mind if others will write just "trivial" or
something like that.
Require some indication in the commit message for code that usually is
covered by RTC, that this commit was done using C-T-R rule.
[X] +1
[ ] 0
[ ] -1
With the volume of commits getting almost up to the 4.0 development days,
I'd like a flag that says that I should review something that I might
otherwise not.
My own votes for 2.,3.,4.,5. are +1, but for 6. my vote is -0.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
