+1 to Kirk’s proposal
> On Aug 17, 2016, at 6:09 PM, Kevin Duling <kdul...@pivotal.io> wrote:
>
> +1 for that
>
>
> On Wed, Aug 17, 2016 at 5:25 PM, Kirk Lund <kl...@pivotal.io> wrote:
>
>> The guidelines written by Chris Beams are designed to fit well within the
>> gui for github. He specifically says try for 50 but then try to keep 69
>> chars as a hard-limit because the github gui will truncate at 69 chars and
>> append ellipse "..." at the end. This mostly affects non-apache committers
>> creating pull requests.
>>
>> I favor loose adherence to these guidelines:
>>
>> 1st line should be limited to 50-69 chars if possible. Subsequent lines
>> should be wrapped at 72 chars.
>>
>> -Kirk
>>
>>
>> On Wed, Aug 17, 2016 at 4:47 PM, Dan Smith <dsm...@pivotal.io> wrote:
>>
>>> Yeah, 50 chars seems a bit short. I think I've been aiming for 72
>>> personally.
>>>
>>> -Dan
>>>
>>> On Wed, Aug 17, 2016 at 4:37 PM, Kirk Lund <kl...@pivotal.io> wrote:
>>>
>>>> Some examples from feature/GEODE-1781-02 which are my latest unmerged
>>>> commits...
>>>>
>>>> 1) 1st line is 62 chars. To shorten to 50: "GEODE-1799: fix javadocs on
>>>> CacheServerStats" or "GEODE-1799: change javadocs from Bridge to Cache"
>>>>
>>>> commit 0a07db189c8b928976ed6554499f15b6a64e1633
>>>> Author: Kirk Lund <kl...@apache.org>
>>>> Date: Wed Aug 17 16:27:52 2016 -0700
>>>>
>>>> GEODE-1799: change javadocs from Bridge Server to Cache Server
>>>>
>>>> 2) 1st line is 80 chars. To shorten to 50: "GEODE-1781: exclude class
>>> from
>>>> AnaylzeSerializableJUnitTest"
>>>>
>>>> commit 55c5df5e4cd6228be1617fb1e92d8d955a703b08
>>>> Author: Kirk Lund <kl...@apache.org>
>>>> Date: Tue Aug 16 09:25:33 2016 -0700
>>>>
>>>> GEODE-1781: exclude LinuxProcFsStatistics$CPU from
>>>> AnaylzeSerializableJUnitTest
>>>>
>>>> 3) 1st line is 59 chars. To shorten to 50: "GEODE-1782: fix stat
>> resource
>>>> equals"
>>>> (the later lines meet our guidelines)
>>>>
>>>> commit 7dc1ce68a483f993adeb613893073d8a7c88a9b7
>>>> Author: Kirk Lund <kl...@apache.org>
>>>> Date: Mon Aug 15 18:35:45 2016 -0700
>>>>
>>>> GEODE-1782: include start timestamp in stat resource equals
>>>>
>>>> * stat resources with different time stamps should not be equal
>>>>
>>>> * StatArchiveWithConsecutiveResourceInstGenerator generates gfs
>> with
>>>> multiple stat resources of same name but different times
>>>>
>>>> * StatArchiveWithConsecutiveResourceInstIntegrationTest confirms
>>>> existence of bug GEODE-1782: StatArchiveReader ignores later stats
>>>> resource with same name as closed stats resource
>>>>
>>>> * ResourceInstTest verifies the underlying issue and fix in
>>>> StatArchiveReader.ResourceInst.equals and the fix
>>>>
>>>> 4) I got this one down to 48 chars!
>>>> (the later lines meet our guidelines)
>>>>
>>>> commit 115070123ec15638ca1189a7349938c35e0d51e0
>>>> Author: Kirk Lund <klund@Kirks-MacBook-Pro.local>
>>>> Date: Mon Aug 15 18:26:16 2016 -0700
>>>>
>>>> GEODE-1781: refactor internal statistics classes
>>>>
>>>> * move internal statistics classes into
>>> com.gemstone.gemfire.internal.
>>>> statistics
>>>>
>>>> * move statistics tests into com.gemstone.gemfire.internal.
>>> statistics
>>>>
>>>> * modify tests to include integration and distributed in names
>>>>
>>>> * modify tests to use TemporaryFolder and TestName rules
>>>>
>>>> On Wed, Aug 17, 2016 at 4:22 PM, Kenneth Howe <kh...@pivotal.io>
>> wrote:
>>>>
>>>>> Agree with Kirk, 50 chars is really short by the time you use up the
>>>> first
>>>>> 12 characters for the Jira tag. If we’re going to have a guideline,
>> I’d
>>>>> rather be longer - somewhat arbitrarily I’d probably make it 20-30
>>> chars
>>>>> more. It’s been a long time since text listings were intended to fit
>>> on a
>>>>> 80x24 dumb terminal, so I don’t see a need to restrict the commit
>>> message
>>>>> headers so severely.
>>>>>
>>>>> I do use the —online option embedded in a local alias I use to look
>> at
>>> a
>>>>> history list of my local repo.
>>>>>
>>>>> Ken
>>>>>
>>>>>> On Aug 17, 2016, at 3:45 PM, Kevin Duling <kdul...@pivotal.io>
>>> wrote:
>>>>>>
>>>>>> The format is very similar to the one most other git shops I've
>>> worked
>>>> in
>>>>>> before use. I don't believe we ever had formal length limits.
>>>>> Typically,
>>>>>> it was:
>>>>>>
>>>>>> <JIRAPROJECT>-####: <Jira Ticket Summary>
>>>>>>>
>>>>>> blank line
>>>>>>
>>>>>> <brief description of fix, usually matching what was placed in the
>>>>> ticket>
>>>>>>
>>>>>>
>>>>>> The Atlassian plugin for IDEA automates a lot of this. There are
>>>> limits
>>>>> on
>>>>>> the length of a jira ticket summary, but I'm not sure what that is.
>>> I
>>>>> ran
>>>>>> in to it when I did my round of CI.
>>>>>>
>>>>>> I don't see a reason to change anything except maybe stress that he
>>>>> lengths
>>>>>> are a guideline, not a hard & fast rule. If more room is needed to
>>>> write
>>>>>> good information, it shouldn't be truncated as it's not unknown to
>>> move
>>>>>> away from a given ticket system.
>>>>>>
>>>>>> On Wed, Aug 17, 2016 at 3:38 PM, Kirk Lund <kl...@pivotal.io>
>> wrote:
>>>>>>
>>>>>>> 50 chars including "GEODE-nnnn: " is awfully short.
>>>>>>> http://chris.beams.io/posts/git-commit/ does say that's just a
>>>> general
>>>>>>> rule
>>>>>>> of thumb and not a hard limit. The author's reasoning seems to be
>>>>>>> specifically for using "git log --oneline" -- does anyone use that
>>>>> option
>>>>>>> with git log? I don't.
>>>>>>>
>>>>>>> I guess another option is to not have to have a guideline if we
>>> don't
>>>>> want
>>>>>>> one... our current git log messages are reasonable and make sense.
>>>>>>>
>>>>>>> -Kirk
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 17, 2016 at 3:21 PM, Kirk Lund <kl...@pivotal.io>
>>> wrote:
>>>>>>>
>>>>>>>> Here's the git commit message guidelines we discussed and voted
>> on
>>>> last
>>>>>>>> year. I just checked and my own git commit message line lengths
>>> have
>>>>>>> grown
>>>>>>>> beyond what we decided to use. Most other are also not following
>>> this
>>>>>>>> guideline.
>>>>>>>>
>>>>>>>> Here's the list of folks who voted last year along with their
>> vote:
>>>>>>>>
>>>>>>>> Anthony Baker +1
>>>>>>>> Vincent Ford +1
>>>>>>>> William Markito +1
>>>>>>>> arghya sadhu +1
>>>>>>>>
>>>>>>>> Do we want to reaffirm this guideline or should it change?
>>>>>>>>
>>>>>>>> -Kirk
>>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: Kirk Lund <kl...@pivotal.io>
>>>>>>>> Date: Wed, Aug 5, 2015 at 3:18 PM
>>>>>>>> Subject: git commit messages
>>>>>>>> To: dev@geode.incubator.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>> Several of us were discussing http://chris.beams.io/posts/
>>>> git-commit/
>>>>> --
>>>>>>>> there are a couple other really good articles about git commit
>>>> messages
>>>>>>> and
>>>>>>>> below is the message style I've been trying to follow.
>>>>>>>>
>>>>>>>> http://chris.beams.io/posts/git-commit/
>>>>>>>> http://www.laurencegellert.com/2013/07/how-to-write-a-
>>> proper-commit-
>>>>>>>> message/
>>>>>>>> http://tbaggery.com/2008/04/19/a-note-about-git-commit-
>>> messages.html
>>>>>>>>
>>>>>>>> GEODE-nn: Begin capitalized and 50 chars or less
>>>>>>>>
>>>>>>>> More detailed explanation with linefeeds to wrap at 72 characters
>>>> after
>>>>>>>> a blank line following the summary.
>>>>>>>>
>>>>>>>> Further paragraphs come after blank lines.
>>>>>>>>
>>>>>>>> - Bullet points are okay, too
>>>>>>>>
>>>>>>>> - Typically a hyphen or asterisk is used for the bullet, followed
>>> by
>>>> a
>>>>>>>> single space, with blank lines in between, but conventions vary
>>> here
>>>>>>>>
>>>>>>>> - Use a hanging indent
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
