이희승 (Trustin Lee) wrote:

Trustin, I'm on the project *management* committee.

I would like to see the code you commit adheres to some standard.

Until this is resolved my right to veto holds so please revert your commit until we figure out the best choice for Javadoc. If you won't revert it, I can do it for you.

Regardless of which we choose something is required to help those using IDE's besides Eclipse. There is no reason why Vi or Emacs users should according to your words, 'pay for what they use'.

I also have to mention that I don't like to go that far. I have to just in order to get this project on rails. You have to understand that you can't break all the rules simply because you think that the rules are bad. I didn't made the rules, and I consider that good practices are also rules we have to follow. If all the implemented classes in the core JVM (ArrayList and List, etc) duplicate the Javadoc, it's for a pretty good reason. You can disagree, but that won't make those good reasons disappear.

PS : for the record, here is the veto definition (http://www.apache.org/foundation/glossary.html) :

*Veto* According to the Apache methodology, a change which has been made or proposed may be made moot through the exercise of a veto by a committer to the codebase <http://www.apache.org/foundation/glossary.html#Codebase> in question. If the R-T-C <http://www.apache.org/foundation/glossary.html#ReviewThenCommit> commit policy is in effect, a veto prevents the change from being made. In either the R-T-C or C-T-R <http://www.apache.org/foundation/glossary.html#CommitThenReview> environments, a veto applied to a change that has already been made forces it to be reverted. Vetos may not be overridden nor voted down, and only cease to apply when the committer who issued the veto withdraws it. All vetos /must/ be accompanied by a valid technical justification; a veto without such a justification is invalid. Vetos only apply to code changes; they do not apply to procedural issues such as software releases.