Open Stack

Excerpts from Thierry Carrez's message of 2015-08-18 10:34:35 +0200:
> Dave Walker wrote:
> > On 17 August 2015 at 15:59, Jeremy Stanley <fungi at yuggoth.org> wrote:
> >> On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
> >> [...]
> >>> OSSA: <YYYY-ZZZ>
> >>> For commits that correspond to vulnerability fixes.
> >> [...]
> >>
> >> I don't think that's going to be feasible. Consider the sequence
> >> with a public security vulnerability... often the OSSA number isn't
> >> assigned until after one or more backports have been approved. With
> >> some careful controls introduced into the VMT process we may be able
> >> to make sure most of these get updated commit messages before they
> >> merge, but would still need a plan to solve for the times when
> >> backported security fixes slip in without an OSSA header in the
> >> commit message.
> 
> That's actually another case where we need to be able to fix up release
> notes after the fact. So my question still stands:
> 
> > We also might need a mechanism to add to release notes when we realize
> > after the fact that a specific commit in past history warrants a
> > highlight. Would some kind of no-change commit do the trick ?
> 
> Dave suggested:
> 
> > Maybe this is a perfect use-case for git-notes?  This means the commit
> > itself isn't touched and the non-scale git-tag space isn't wasted?
> 
> It definitely seems to be the perfect match: adding notes to commits
> lets us document release notes both during and after backports, without
> altering commit messages.
> 
> The trick is that like git tags, git notes do not appear to be
> code-reviewable using Gerrit, they are directly pushed by people with
> Push Refs rights (or by Gerrit itself on merge to store approval
> details). So ideally we want to generate them from properly
> code-reviewed data.
> 
> We could have a Gerrit plugin (inspired from the reviewnotes plugin)
> that takes specific headers from commit messages and populate a
> "releasenote" git note accordingly.
> 
> For after-the-fact git notes (say, to add an OSSA reference to an
> already-merged commit), we could have a section in the
> openstack/releases proposed change that describes additional
> "releasenote" git notes to push to old commits when the change is accepted.

We could use the openstack/releases repo to track all of them, so
the process is consistent for all types of stable patches.

Within the releases repo, we want to separate the release notes
from the deliverables files, because we want to support adding notes
independent of creating a release.

OK, I think this could work, but I'm worried about by whom and when.

Would it make sense to start with something simple, like just asking
folks to write RST files with release notes in the releases repository?
That at least *captures* the data, and we can enforce it as we review
stable branch patches.

Doug

> 
> Something like:
> 
> additional-notes:
>   cc6c50ee23f336d08e4fe833070943c0025a205d:
>     OSSA: 2015-022
>   fcfbf8eb0e0d42ff54bd014bc9e43f5f48bd7a68:
>     Release-note: >
>       Fixing bug 1237534 actually results in a 10x performance
>       improvement listing networks connected to an instance
> 
> That way all note content is properly reviewed before they make it to
> the git notes.
> 
> Then pbr would just parse git notes instead of commit messages to
> generate releasenotes files in the code tarballs.
>