couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <chewbra...@apache.org>
Subject Re: [VOTE] Git Commit Messages
Date Wed, 29 May 2013 01:36:26 GMT
I'm a big +1 to proposal 1) for better and more structured commit messages.
I'm -1 to the addition of adding the JIRA ticket in the message itself, as
that should be 50 characters or less, and you can have the ticket id in the
full message body and also in the original topic branch name.

As for proposal 2), I think that anything we can do to simplify creation of
releases is a good direction to go in. I do wonder if generating a release
from the commit log requires us to change our approach to commits in the
master branch. Should every commit that lands in master be a single commit
that is a fully squashed topic branch corresponding to a JIRA ticket? It
seems potentially problematic to require a direct mapping between every
commit and release note line items. Overall I like the idea of automating
release notes as much as possible.


-Russell


On Tue, May 28, 2013 at 12:44 PM, Robert Newson <rnewson@apache.org> wrote:

> Benoit,
>
> Yes, agreed. I think this joins up with Adam's point too. We need to
> take more care with commit messages in general, and how features/fixes
> are represented in git. We have a thread on the latter already but, to
> address your points, we can include this style of commit on the merge
> commit for those features/fixes that are better represented as
> multiple commits.
>
> I concede the point that we can't ditch NEWS and CHANGES soon, so I'll
> retract that question. For 1.4, I suggest we try to base our release
> notes from the git log, with whatever modifications we end up making,
> and only then decide what our new process looks like.
>
> B.
>
>
>
> On 28 May 2013 20:00, Benoit Chesneau <bchesneau@gmail.com> wrote:
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message