couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [VOTE] Git Commit Messages
Date Tue, 28 May 2013 19:00:52 GMT
Still +1 on the general idea but thinking more of it we should keep
the current Changes and if the proposal pass just amend it with the
dynamic results. The main reason for that is that until now we didn't
have any rule when it was about writing this commit message. So an
automated way will lost a lot of info. Also some commits aren't atomic
 and lot of changes have been dispatched on 3 3 or more commits.
sometimes we even have small typos commit and such.

Which conduct me to think that if we go to such changes log then we
also need to change the way we handle commits on the master and
release. Ie. only atomic or self-described commits should go on
master. The point is that without control on the commits the changelog
will quickly become useless. Thoughts?

- benoit

On Mon, May 27, 2013 at 5:44 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> +1
>
> On Mon, May 27, 2013 at 5:42 PM, Robert Newson <rnewson@apache.org> wrote:
>> Hi All,
>>
>> Rather than manually maintaining the NEWS and CHANGES files I'd like
>> to save us time by using the output of git log as our release notes
>> after 1.3.1.
>>
>> To make this work we'll need to be better at commit messages. The de
>> facto standard for git commit messages is described at
>> http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
>> and I would like us all to commit to using these guidelines, with some
>> clarifications:
>>
>> 1) The last line of the commit should mention the JIRA ticket.
>> 2)  The first line does *not* end with punctuation.
>>
>> Here's a good, albeit sarcastic, example;
>>
>> --
>> Report name of rejected attachment
>>
>> Some users make requests from inside a black box with a blindfold on
>> and their eyes closed and are thus sometimes unaware of the names of
>> their own attachments. Let's help these people.
>>
>> BugzID: 17669
>> --
>>
>> The first line of each log between releases will form the release notes.
>>
>> I'd like to vote on two questions;
>>
>> 1) That we adopt the git commit message guidelines above.
>> 2) That we delete NEWS/CHANGES from master before the next release after 1.3.1.
>>
>> The voting rules are lazy consensus with a 72 hour waiting period. You
>> do not have to vote if you agree, though you are welcome to do so. If
>> you do vote against I encourage you to include a constructive reason
>> or suggest an alternative.
>>
>>
>> B.

Mime
View raw message