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)
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
