Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3C96ECF36 for ; Wed, 7 Jan 2015 22:12:07 +0000 (UTC) Received: (qmail 18768 invoked by uid 500); 7 Jan 2015 22:12:08 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 18721 invoked by uid 500); 7 Jan 2015 22:12:08 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 18710 invoked by uid 99); 7 Jan 2015 22:12:08 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jan 2015 22:12:08 +0000 Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id A22A41A012A for ; Wed, 7 Jan 2015 22:12:07 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id dc16so4667404qab.8 for ; Wed, 07 Jan 2015 14:12:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.89.18 with SMTP id u18mr8456983qgd.20.1420668726567; Wed, 07 Jan 2015 14:12:06 -0800 (PST) Received: by 10.229.89.137 with HTTP; Wed, 7 Jan 2015 14:12:06 -0800 (PST) In-Reply-To: <54ADA6C2.8070005@gmail.com> References: <54AD95B2.5020804@gmail.com> <54ADA6C2.8070005@gmail.com> Date: Wed, 7 Jan 2015 17:12:06 -0500 Message-ID: Subject: Re: [VOTE][LAZY] Format all supported branches From: Christopher To: Accumulo Dev List Content-Type: multipart/alternative; boundary=001a11c11e46ca6a64050c1736d2 --001a11c11e46ca6a64050c1736d2 Content-Type: text/plain; charset=UTF-8 Some of the checkstyle rules catch stuff in javadocs, which even I don't typically think to look for (like invalid HTML), and I'm pretty pedantic already when it comes to javadocs. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jan 7, 2015 at 4:36 PM, Josh Elser wrote: > +1 for that. I feel bad when I see you constantly come across after my > commits when I inevitably bork some Javadoc. > > > Christopher wrote: > >> Basically, hard enforcement (failing the build) makes us share >> responsibility for quality control. >> >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> On Wed, Jan 7, 2015 at 4:28 PM, Christopher wrote: >> >> Fail (which is what I think we want, especially for the broken javadoc >>> issues I've been seeing), but it could be configured either way. What I >>> wouldn't want to happen is for them to be printed and simply ignored. If >>> we're going to have to go back and fix them (instead of ignoring), I'd >>> rather they fail, so the person who introduced the problem is held >>> responsible for fixing before they push. The plugin can also be skipped, >>> or >>> configured to not fail, with command-line options. >>> >>> One great thing about Checkstyle rules, is they have *very* good >>> descriptions about what is wrong. So, when you do see an error, it is >>> typically a very obvious fix... and they give you the line number, too. >>> >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii >>> >>> On Wed, Jan 7, 2015 at 4:12 PM, Mike Drob wrote: >>> >>> Will the checkstyle rules fail the build or just print warnings? >>>> >>>> On Wed, Jan 7, 2015 at 3:11 PM, Christopher >>>> wrote: >>>> >>>> In the long run, the rules will (hopefully) save me work following up >>>>> fixing bad javadocs and trivial warnings. >>>>> >>>>> >>>>> -- >>>>> Christopher L Tubbs II >>>>> http://gravatar.com/ctubbsii >>>>> >>>>> On Wed, Jan 7, 2015 at 4:03 PM, Eric Newton >>>>> >>>> wrote: >>>> >>>>> +0 >>>>>> >>>>>> I don't think it's worth the disruption, but I don't mind if you're >>>>>> >>>>> going >>>> >>>>> to do all the work. >>>>>> >>>>>> >>>>>> On Wed, Jan 7, 2015 at 3:47 PM, Mike Drob >>>>>> >>>>> wrote: >>>> >>>>> 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 >>>>>>>> >>>>>>> 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 >>>>>>>>> >>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> >> --001a11c11e46ca6a64050c1736d2--