Open Stack

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.

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.

-- 
Thierry Carrez (ttx)