Re: [VOTE] C-T-R for any translation fixes
On 3/8/2010 2:00 PM, Konstantin Kolinko wrote: I propose to relax our RTC policy and use CTR for the types of changes listed below: 2010/3/8 Konstantin Kolinkoknst.koli...@gmail.com: 1. We already have Commit-Then-Review for any documentation, including JavaDoc and code comments. Already decided. No need to vote. +1 (Correct docs/javadocs require no RTC) Still saying +1 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: [X] +1 [ ] 0 [ ] -1 3. Allow C-T-R for any whitespace changes: [X] +1 [ ] 0 [ ] -1 4. 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. [X] +1 [ ] 0 [ ] -1 5. Any fixes for any translations. 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 6. 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. [ ] +1 [X] 0 [ ] -1 Other comments I'm not worrying about this. If someone has the time and energy to fix typos, docs - that is awesome. -Tim - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 08/03/2010 17:34, Konstantin Kolinko wrote: 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. +1 for line endings, +0 for the rest 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. +1. Only if required to ease back-porting. 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. +1 5. Any fixes for any translations. +1 providing that native2ascii has been used 6. Should we mark C-T-R commits somehow in the commit message? E.g. writing C-T-R or trivial in the message? Putting CTR at the start works for me. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
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=896544r2=896543pathrev=896544diff_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 \u 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
Re: [VOTE] C-T-R for any translation fixes
Your vote proposal is not very much readable.
Please make a standard single request for vote and
check boxes +1, -1 (+0, -0 are irrelevant thought, but might be added as well)
On 03/08/2010 06:34 PM, Konstantin Kolinko wrote:
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
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.
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=896544r2=896543pathrev=896544diff_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.
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.
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 \u 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.
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing C-T-R or trivial in the message?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
CTR for non code area in TC : +1
2010/3/8 Mladen Turk mt...@apache.org:
Your vote proposal is not very much readable.
Please make a standard single request for vote and
check boxes +1, -1 (+0, -0 are irrelevant thought, but might be added as
well)
On 03/08/2010 06:34 PM, Konstantin Kolinko wrote:
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
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.
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=896544r2=896543pathrev=896544diff_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.
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.
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 \u 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.
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing C-T-R or trivial in the message?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
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
[ ] -1
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=896544r2=896543pathrev=896544diff_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
[ ] 0
[ ] -1
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
[ ] 0
[ ] -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 \u 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.
[ ] +1
[ ] 0
[ ] -1
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.
[ ] +1
[ ] 0
[ ] -1
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
Re: [VOTE] C-T-R for any translation fixes
On 03/08/2010 08:00 PM, Konstantin Kolinko wrote: I propose to relax our RTC policy and use CTR for the types of changes listed below: Usually a vote has a single voting item, but all those things you've put to vote are something many projects already have as a policy. Allow C-T-R for changes to svn properties: [ ] +1 [ ] 0 [X] -1 -1 because it can mean anything and nothing. Changing line endings, executable flag, mime type all falls into svn properties for which change one needs a good reason. If you meant svn logs and svn commit message typos then +1 for those (but you should said that) Allow C-T-R for any whitespace changes: [X] +1 [ ] 0 [ ] -1 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. [X] +1 [ ] 0 [ ] -1 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 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 Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 08.03.2010 20:00, Konstantin Kolinko wrote: I propose to relax our RTC policy and use CTR for the types of changes listed below: 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 [X] 0 [ ] -1 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. Allow C-T-R for any whitespace changes: [X] +1 [ ] 0 [ ] -1 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. 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. [X] +1 [ ] 0 [ ] -1 5. Any fixes for any translations. 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 6. Should we mark C-T-R commits somehow in the commit message? E.g. writing C-T-R or trivial in the message? [X] +1 [ ] 0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
2010/3/8 Mladen Turk mt...@apache.org: On 03/08/2010 08:00 PM, Konstantin Kolinko wrote: Allow C-T-R for changes to svn properties: [ ] +1 [ ] 0 [X] -1 -1 because it can mean anything and nothing. Changing line endings, executable flag, mime type all falls into svn properties for which change one needs a good reason. If you meant svn logs and svn commit message typos then +1 for those (but you should said that) I meant svn:eol-style, svn:mime-type, svn:keywords, svn:executable. svn:log is a revision property which is repository-wide, so it is not a subject of RTC. My reasoning is that because we distribute our sources as zip/tar.gz archives, which do not have svn properties, none of those properties are essential. Also, 1. I believe that every committer has their reasons when applying the change, and I trust those reasons. 2. C-T-R still allows you to object, and also to revert the change immediately. It is just a question of whether we need three votes here. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
Overall, We'd be better off leaving everything as it is.
6.0.24 had a huge amount of changes, and also a series of rapid
regressions, and probably more to follow.
To keep the branch stable, we should work in a stable manner, RTC has
worked well for that
Filip
On 03/08/2010 10:34 AM, Konstantin Kolinko wrote:
1. We already have Commit-Then-Review for any documentation, including
JavaDoc and code comments.
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.
+1
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.
-1, makes tracing down when and how code changed a pain in the rear.
It's not beneficial.
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=896544r2=896543pathrev=896544diff_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.
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.
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 \u 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.
6. Should we mark C-T-R commits somehow in the commit message?
E.g. writing C-T-R or trivial in the message?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 03/08/2010 12:00 PM, Konstantin Kolinko wrote:
I propose to relax our RTC policy and use CTR for the types of changes
listed below:
2010/3/8 Konstantin Kolinkoknst.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
[X] 0
[ ] -1
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=896544r2=896543pathrev=896544diff_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
[ ] 0
[X] -1
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
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 \u 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.
[ ] +1
[X] 0
[ ] -1
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.
[ ] +1
[X] 0
[ ] -1
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
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On Mon, Mar 8, 2010 at 2:00 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: Allow C-T-R for changes to svn properties: [ ] +1 [ X ] 0 Allow C-T-R for any whitespace changes: [ ] +1 [ X ] 0 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. [ X ] +1 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 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. [ ] +1 [ X ] 0 Yoav - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 03/09/2010 01:47 AM, Filip Hanik - Dev Lists wrote: Overall, We'd be better off leaving everything as it is. 6.0.24 had a huge amount of changes, and also a series of rapid regressions, and probably more to follow. To keep the branch stable, we should work in a stable manner, RTC has worked well for that That is also what I am thinking, more eyes to spot errors warrants a more stable tomcat. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] C-T-R for any translation fixes
On 03/09/2010 01:47 AM, Filip Hanik - Dev Lists wrote: Overall, We'd be better off leaving everything as it is. 6.0.24 had a huge amount of changes, and also a series of rapid regressions, and probably more to follow. To keep the branch stable, we should work in a stable manner, RTC has worked well for that Asking for a vote on a comment typo or code formatting is simply insane. I don't think that is the purpose of RTC policy. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
