Open Stack

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)
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170921/f8a53298/attachment.sig>