accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: [VOTE][LAZY] Format all supported branches
Date Wed, 07 Jan 2015 20:36:58 GMT
+1

Are you automating the process so that you can re-apply the same steps
in one year?

On Wed, Jan 7, 2015 at 3:31 PM, Christopher <ctubbsii@apache.org> wrote:
> Can do. It's a bit more work for me, because I have to repeat the same
> actions over and over again, but if it helps history look a little cleaner,
> i can do it, and just stick to -sours and repeat for the next branch..
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Wed, Jan 7, 2015 at 3:25 PM, Mike Drob <madrob@cloudera.com> wrote:
>
>> Please do not do formatting during merge conflict resolution, and make
>> those be separate commits.
>>
>> On Wed, Jan 7, 2015 at 2:23 PM, Josh Elser <josh.elser@gmail.com> wrote:
>>
>> > ack'ed
>> >
>> >
>> > John Vines wrote:
>> >
>> >> +1
>> >>
>> >> On Wed, Jan 7, 2015 at 3:12 PM, Christopher<ctubbsii@apache.org>
>> wrote:
>> >>
>> >>  To make it easier to apply some minimal checkstyle rules for
>> >>> ACCUMULO-3451,
>> >>> I'm announcing my intentions to do a full, one-time, auto-format and
>> >>> organize imports on all our supported branches (1.5, 1.6, and master)
>> to
>> >>> bring us up to some degree of compliance with our agreed-upon
>> formatting
>> >>> standards.
>> >>>
>> >>> Benefits:
>> >>> To have additional checks, in particular against javadoc problems and
>> >>> other
>> >>> common trivial warnings in the build.
>> >>> To ensure less divergence from our agreed-upon formatting standards.
>> >>> Formatting first makes it much less tedious and easier on me to add
>> these
>> >>> checks to the build.
>> >>>
>> >>> Issues I've considered:
>> >>> I will deal with all the merge conflicts.
>> >>> I will ignore generated thrift code.
>> >>> Conflicts with new code in people's branches should be minimal (and
>> >>> easily
>> >>> resolved by formatting according to our standards).
>> >>> Regarding concerns about history tracking, in general, each format
>> change
>> >>> is small, but they are numerous. So, the impact on tracking history
>> >>> should
>> >>> be very minimal (you'll see things like a brace moved to the same line
>> as
>> >>> the else statement it is associated with... stuff that won't generally
>> >>> affect your ability to debug).
>> >>> I'll also do a "format only" commit, separately from any substantive
>> >>> changes regarding the rule changes, so the mass formatting change will
>> >>> happen in one place, and it will also be easy to revert, if absolutely
>> >>> necessary.
>> >>>
>> >>> I'll give this 24 hours (it can be reverted if somebody objects after
>> >>> that).
>> >>>
>> >>> --
>> >>> Christopher L Tubbs II
>> >>> http://gravatar.com/ctubbsii
>> >>>
>> >>>
>> >>
>>

Mime
View raw message