accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE][LAZY] Format all supported branches
Date Wed, 07 Jan 2015 20:31:23 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message