Open Stack

On 17-09-22 15:07:14, Doug Hellmann wrote:
> 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
> 

Sounds good, I've created a bug we can start linking reviews to (along
with documenting the final plan).

https://bugs.launchpad.net/openstack-requirements/+bug/1719006

-- 
Matthew Thode (prometheanfire)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170922/35d7c727/attachment.sig>