Open Stack

Excerpts from Doug Hellmann's message of 2016-09-30 14:57:53 -0400:
> I have prepared a patch to openstack/releases to re-tag all of the
> current release candidates using their final release version numbers.
> 
> I could use some assistance reviewing the results to ensure that I
> have not left anything out and that the version numbers are all
> correct.
> 
> This patch also includes a "diff-start" value for each release so
> that the release announcement emails will include the full history
> of a release. The values should match the tag used to create the
> stable/mitaka branch for each repository (so that all of the DAG
> content between that point and the tip of stable/newton are included).
> 
> Please take a few minutes between now and Thursday to look over the
> deliverable file changes for your projects, and comment on the patch
> if you spot anything that looks off.
> 
> https://review.openstack.org/#/c/380478
> 
> Thanks!
> Doug
> 

There seems to be a little confusion about the diff-start values,
which makes sense because it's not something we've ever asked you
to look at before and I didn't give much detail. I'm asking for
help with it this cycle, because we got the announcements wrong
last cycle and added diff-start to address that problem.

When we compute the changes for newton, we want to look at the
entire history of newton. That includes the stable/newton branch,
but it also includes a large part of the master branch between the
point where we created the stable/mitaka branch and the stable/newton
branch. It does *not* include changes that were on the stable/mitaka
branch, because presumably those were either unique (and not part
of newton) or backports (and will be on the master branch segment
we're scanning).

Given a history graph like this:

m  n  m
i  e  a
t  w  s
a  t  t
k  o  e
a  n  r
|  |  |
V  V  V

      C - master HEAD
      |
   B  | - newton RC*, to be newton final
   |  |
A  |  | - most recent mitaka release
|  |  |
|  D' D - patch backported from master to stable/newton
|  |  |
E  |  | - mitaka RC2
|  |  |
F  |  | - patch only on newton (such as a requirements update)
|  \  |
|   \ |
|    \G - newton RC1 (start of stable/newton branch)
\     |
 H'   H - a patch in newton that was backported to stable/mitaka
  \   |
   \  I - a patch in newton but not backported to stable/mitaka
    \ |
     \J - mitaka RC1 (start of stable/mitaka)
      |
      K - older patch before mitaka RC1

We want to include B (as the RC candidate we are re-tagging), D'
(as a patch that was backported to stable/newton after the branch
was created), G (as the first release candidate for newton), H (a
patch in newton that was also backported to stable/mitaka), and I
(a patch that was not backported to mitaka). Then we want to stop
when we reach J, the point where stable/mitaka was created.

We do not want to include H' (because it is redundant with the copy
of H in the master segment) or F, E, or A (because those are all
commits/tags that were added to stable/mitaka after it was branched
from master).

The diff-start value therefore should correspond with the tag at
J.  I am reasonably confident that for mitaka that is the RC1 tag
for all of the milestone projects. I'll be working on verifying
that mechanically early this week. If you know for certain that
your project was branched later than RC1, let me know.

Doug