On 28/Jul/2009 17:19, Andrew John Hughes wrote: > 2009/7/28 Jesse Wilson <[email protected]>: >> Harmony folks, >> I've started to watch the Harmony commit logs and I saw a commit that I >> disagree with! I figured that it was a good opportunity for a discussion... >> >> The commit fixed some style problems in the java.util.concurrent package. It >> fixed whitespace problems and Javadoc inconsistencies, replacing >> <tt>Object</tt> with {...@code Object}. In general, such changes are >> improvements, but we should make an exception for third-party code. The >> unnecessary deltas will make merging and integrating future changes from >> upstream much more labor intensive. And if it's more difficult to integrate >> patches, we won't do so very frequently! >> >> This advice is from experience. I work on Android's Dalvik classlibraries, >> which is itself downstream of Harmony. We've made a broad exception to our >> project's style guide so we can avoid reformatting code. This saves me a >> significant amount of merging effort. >> >> Thanks! >> Jesse >> > > I'd second that. Merging work is tedious at best without making > things harder by introducing mechanical changes. Especially with > whitespace changes, these have to be basically reapplied from scratch > to the new source file being merged in.
Agreed. > With GNU Classpath, we keep external sources such as the JSR166 > sources physically separate (in external/*) to avoid such occurrences > as best we can. We do (did?) that too, in the concurrent/standard directory. Should be no gratuitous formatting etc. done in there. (It used to be pulled in as an svn:externals but that breaks version control of the tree.) Regards, Tim
