harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Avoid reformatting third-party code?
Date Tue, 28 Jul 2009 16:51:51 GMT
On 28/Jul/2009 17:19, Andrew John Hughes wrote:
> 2009/7/28 Jesse Wilson <jessewilson@google.com>:
>> 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

Mime
View raw message