accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [VOTE][LAZY] Format all supported branches
Date Wed, 07 Jan 2015 20:47:00 GMT
Also, if you're using Eclipse to do the auto-format, please check for
trailing white-space on otherwise empty javadoc lines.

If you automate this in some fashion outside of Eclipse (because other
people may prefer other editors), this would be a useful script to add to a
top-level dev-tools folder.

On Wed, Jan 7, 2015 at 2:36 PM, David Medinets <david.medinets@gmail.com>
wrote:

> +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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message