Reno is confused when a stable tag is merged with the master branch

[Sylvain Bauza]

There was a discussion at the OpenStack RelMgmt contributor meetup in Austin about the possible risk that Reno could be confused by the OpenStack habit to merge the stable branch into the master one.

AFAICT, I can see it as a real problem on the "unreleased" page (not specifically asking for either a branch or a tag) :

http://docs.openstack.org/releasenotes/cinder/unreleased.html#id1

[Stephen Finucane (stephenfinucane)]

Demo available here https://github.com/stephenfin/reno-bug-1588309

[Doug Hellmann (doug-hellmann)]

We changed the release process to stop doing this a couple of years ago, so I think the issue is more likely to be a problem for older series. There really isn't much we can do about it, though. If you merge branches, then reno can't tell them apart because *they are now the same branch*.

We could extend the options for including/excluding versions from the output, I guess, but that would require a bunch of manual configuration within the repo that has the merged data.

[Stephen Finucane (stephenfinucane)]

In my case, I'm seeing this when trying to use reno for Sphinx. Those folks insist on basing bugfixes against the stable branch (they only support the last release) and then merging back into master on a regular basis. This confuses reno mightily.

One thing I was thinking is to keep track of the releasenotes we do find. If one is found on multiple branches, we could assign it to the oldest version. I'm not sure if this is possible though.

[Stephen Finucane (stephenfinucane)]

I've added another version here: https://github.com/stephenfin/reno-bug-1588309-2

This one seems to be even more broken, picking up only the changes made _after_ 1.0.0. The difference is where we do the tagging in the original repo, our log looks like this.

    * 25f810f (HEAD -> master) Merge branch 'stable/1.0'
    |\
    | * 37adb10 (tag: 1.0.1, stable/1.0) Fix a bug on stable
    * | e12c6cf Fix a bug on master
    * | 37a0ae9 doc: Handle multiple branches in release notes
    |/
    * af01c51 (tag: 1.0.0) Release 1.0
    * 0faba45 Integrate reno
    * a7beb14 (tag: 0.1.0) Add documentation
    * e23b0c8 Add gitignore
    * ff980c7 Initial commit

The other one looks like so:

    * 7df1078 (HEAD -> master) Merge branch 'stable/1.0'
    |\
    | * 9723350 (tag: 1.0.1, stable/1.0) Fix a bug on stable
    | * 49e2158 (tag: 1.0.0) Release 1.0
    * | ad13f52 Fix a bug on master
    * | 81b6b41 doc: Handle multiple branches in release notes
    |/
    * 0faba45 Integrate reno
    * a7beb14 (tag: 0.1.0) Add documentation
    * e23b0c8 Add gitignore
    * ff980c7 Initial commit

I think https://bugs.launchpad.net/reno/+bug/1748162 is probably related to this.

[Stephen Finucane (stephenfinucane)]

After discussing with dhellmann on the mailing list, it seems this is because reno is *branch* based - not *version* based. Most (all?) OpenStack projects work on a trunk-based model, where they branch off before a release and then do all release stuff on the branch. Bugfixes are made on the *master branch* and then cherry-picked to the release branch. However, in this case, we're using something similar to git-flow model, where we make the fixes on the *release branch* and merge back to the master branch. Because we're merging back from a release branch to master, reno can't distinguish between the changes.

We could solve this by changing to a *version* based system. In this system, we would scan all branches first, then remove duplicate changes from the newer branches. This would ensure the stuff brought in from the merge is not counted multiple times. However, sometimes we _do_ want to include this information. AS noted on IRC:

  If a note appears on a branch, it should show up in the release history for that branch, even if that means it shows up in multiple places. If I fix a bug in 10.0.1 and backport that to 9.5.2 then users who installed 10.0.0 have just as much right to know the bug was fixed when they go to upgrade as users of 9.5.1

This means that, should we wish to enable this behavior, we should make it possible to switch behaviour.

I need to investigate if this is something anyone cares enough for. Until then, this serves as a reminder to myself of what we discussed. We should also document this for other users in an assumptions section.

[Stephen Finucane (stephenfinucane)]

Discussion starts here --> http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2018-02-08.log.html#t2018-02-08T17:37:10

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/542759

[Doug Hellmann (doug-hellmann)]

The bug tracker for reno has moved to storyboard: https://storyboard.openstack.org/#!/project/933