Open Stack

Excerpts from Tony Breeds's message of 2017-09-21 20:20:22 -0500:
> On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:
> > Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> > > On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> > > 
> > > > I like the idea. I'm not sure why, if the constraints file is only used
> > > > for the dependency installation step, we still need tox_install.sh?
> > > 
> > > Right now that isn't true, when we get something like my idea
> > > implemented we'd still need the tox_install.sh in projects that need
> > > services (not published on pypi) like horizon plugins or neutron stadium
> > > projects.   Fixing that issue is a totally different discussion, one I
> > > started at the PTG but I need to let those conversations settle and do
> > > research on wasy to fix that.
> > > 
> > > > If
> > > > that's just to avoid updating the URL when we create branches, I can
> > > > live with continuing to do that step if we figure out some other way to
> > > > minimize the open race window.
> > > 
> > > So lets check we're on the same page with the race window point.  At the
> > > moment the process looks like:
> > > 1. projects tag RC1 and when generate a stable/series branch.
> > > 2. We generate a reviews that updates .gitreview
> > > 3. We generate a reviews that updates .tox.ini
> > > 4. time passes
> > > 5. requirements creates a stable/series branch
> > > 6. requirements thaws
> > > 
> > > Now the race is that if projects merge the patch from step 3 before step
> > > 5 they're broken (on stable/series) because there isn't a
> > > 'stable/series' in the requirements repo.  There are some additional issues
> > > for cycle-trailing projects but nothing radically different.
> > > 
> > > Correct?
> > > 
> > > Assuming I have that right  In the new world:
> > > 
> > > 0. requirements publish master.txt and series.txt
> > > 1. projects tag RC1 and when generate a stable/series branch.
> > > 2. We generate a reviews that updates .gitreview
> > > 3. We generate a reviews that updates .tox.ini
> > > 4. time passes
> > > 5. requirements creates a stable/series branch
> > > 6. requiremenst now publish series.txt, new_series.txt and master.txt
> > > 6. requirements thaws
> > 
> > Where in that sequence do we make the change so that we're not
> > publishing to series.txt from the new stable branch in requirements and
> > from master in requirements? Between step 4 and 5? Or is the job smart
> > enough to not do that?
> 
> Right now the job is dumb, but yes we'd teach the job to detect that's
> it's a stable branch and only publish it's series branch.  We also teach
> the job to not publish to $series.txt if that stable branch exists.
> 
> So I think the publish job looks like:
> 
> ---
> # preamble
> # typed directly into email so be warned ;P
> # We probably want to check if ZUUL_BRANCH is the correct variable to
> # use.
> case "$ZUUL_BRANCH" in
> stable/*)
>     series=$(basename "$ZUUL_BRANCH")
>     git show origin/$ZUUL_BRANCH:upper-constraints.txt > publish/constraints/upper/${series}.txt
> ;;
> master)
>     for series in queens master ; do
>         if ! git rev-parse origin/stable/${series} ; then
>             git show origin/master:upper-constraints.txt > publish/constraints/upper/${series}.txt
>         fi
>     done
> ;;
> esac
> # postample
> ---
> 
> So using the queens release as an example:
> 
> Jan 22 - Jan 26    R-5 Requirements freeze
>                     NOTES: openstack/requirements (master) publishes {queens,master}.txt
> Jan 29 - Feb 02    R-4          
> Feb 05 - Feb 09    R-3    RC1 target week
>                     ACTIONS: Projects create stable/queens branches
>                     ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
>                     ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS changes
> Feb 12 - Feb 16    R-2
>                     ACTIONS: Projects create stable/queens branch for openstack/requirements
>                     ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
>                     ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS changes
>                     ACTIONS: Make sure master publishes {rocky,master}.txt
>                              (optionally add the S release at this point, it doesn't hurt)

We could add new "future" series names as soon as we know them, since we
would just be publishing to a file that nothing uses.

> Feb 19 - Feb 23    R-1    
> Feb 26 - Mar 02    R+0    Queens release
> Mar 05 - Mar 09    R+1          
> Mar 12 - Mar 16    R+2    Queens cycle-trailing release deadline
> 
> There's a whole other side issue about how long requirements is frozen
> for.  Ignoring that do you think the above process will remove the race,
> and mean that EOL branches can possibly continue to run tests?
> 
> 
> Yours Tony.

Yes, that does look like a sound approach.

Doug