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 EBAC1C8E6 for ; Wed, 7 Jan 2015 20:12:35 +0000 (UTC) Received: (qmail 51838 invoked by uid 500); 7 Jan 2015 20:12:37 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 51798 invoked by uid 500); 7 Jan 2015 20:12:37 -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 51787 invoked by uid 99); 7 Jan 2015 20:12:36 -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 20:12:36 +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 871B11A003F for ; Wed, 7 Jan 2015 20:12:36 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id dc16so4226355qab.8 for ; Wed, 07 Jan 2015 12:12:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.55.197 with SMTP id v5mr7811529qag.59.1420661555287; Wed, 07 Jan 2015 12:12:35 -0800 (PST) Received: by 10.229.89.137 with HTTP; Wed, 7 Jan 2015 12:12:35 -0800 (PST) Date: Wed, 7 Jan 2015 15:12:35 -0500 Message-ID: Subject: [VOTE][LAZY] Format all supported branches From: Christopher To: Accumulo Dev List Content-Type: multipart/alternative; boundary=001a11c2ef8e5961ec050c158b6a --001a11c2ef8e5961ec050c158b6a Content-Type: text/plain; charset=UTF-8 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 --001a11c2ef8e5961ec050c158b6a--