Open Stack

Excerpts from Robert Collins's message of 2015-08-04 06:43:48 +1200:
> On 4 August 2015 at 02:46, Alexis Lee <alexisl at hp.com> wrote:
> > Thierry Carrez said on Mon, Aug 03, 2015 at 02:57:39PM +0200:
> >> 1. we can maintain a Changelog document directly in the source code.
> >> Rather than being straightly backported from master, commits with
> >> significant changes would be amended to additionally modify that document.
> >
> > Wouldn't this cause a lot of rebasing as everyone tries to get in at the
> > top?
> >
> >> 2. we come up with a keyword in commit messages ("ReleaseNotes:" ?) and
> >> amend only the commit message of significant backports. Automation picks
> >> up those and autogenerates a Release Notes document that gets included
> >> in generated source code tarballs.
> >
> > Whichever solution we pick - should we also adopt it on master? Naively
> > it sounds useful to be able to generate release notes for master too.
> > And this avoids inconsistency between master and stable beyond that
> > required to rebase.
> >
> > Explanations of the many ways I'm wrong are always appreciated.
> 
> I think you're right on.
> 
> Something with the same process as ChangeLog generation today - read
> from git, process, output document - will be much less fragile for
> merges.

We could use the same convention for highlighting changes in libraries,
and pull the messages out for the release announcements.

How detailed do we want release notes to be? For example, do we need to
worry about supporting multiple paragraphs or ASCII art or anything like
that?

Doug

> 
> -Rob
>