Agreed!
On Thu, Jun 6, 2013 at 5:48 PM, Robert Newson <rnew...@apache.org> wrote: > Ok, I think everyone is over-reading my suggestion to drive release > notes from commit messages. I'm sure there will always be a manual, > human step to convert the commit messages between two points into > release notes, I'm just saying that if we are consistent with our > commit messages and take the time to write good ones, that we can > drive that effort close to zero. > > Commit messages cannot be edited after the fact but git does support > annotations to existing commits for that kind of fix-up. > > Let's just agree to follow the same standard of commit message for now. > > > On 6 June 2013 11:39, Noah Slater <nsla...@apache.org> wrote: > > My concern with commit messages -> release notes is that we're human, and > > mistakes will happen. How easy will it be to go in and edit commit > > messages? If we can do that, then we can write a tool that generates the > > release notes, and put the onus on committers to edit commit messages as > > necessary until the release notes are representative. Perhaps this is a > > good way of enforcing Git hygiene? > > > > > > > > > > On 6 June 2013 09:40, Benoit Chesneau <bchesn...@gmail.com> wrote: > > > >> On Thu, Jun 6, 2013 at 10:26 AM, Benoit Chesneau <bchesn...@gmail.com> > >> wrote: > >> > On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith <gar...@apache.org> > wrote: > >> >> I agree with Jason and Bob, the simplest way is going to be the > easiest > >> for us to implement. > >> >> > >> >> With us wanting to use commit messages in the release notes, could we > >> not mark specific commit messages e.g. [Release Notes] so that only > >> specific commit messages get added into the release notes and other > commits > >> get ignored. > >> >> > >> >> > >> > > >> > why would you want to parse a commit message to find a release branch > >> > when you could just do > >> > > >> > $ git branch -a > >> > $ git checkout <branchname> > >> > > >> > ? > >> > > >> > - benoit > >> > >> > >> mmmm taking some coffee i sbetter, but having a commit message > >> formmatted like this: > >> > >> > >> Short description in 1 line > >> > >> description > >> > >> close #COUCHDB-XXXX > >> > >> > >> where final line can be > >> > >> - `close TICKET` for features > >> - `fix TICKET` for fixes > >> > >> works generally well to build changelogs and reports. Also the 1 line > >> on top could also be used in messaging systems :) > >> > >> - benoit > >> > > > > > > > > -- > > NS >
