Open Stack

Excerpts from Sachi King's message of 2016-06-30 14:24:45 +1000:
> On Tue, Jun 28, 2016 at 9:38 AM, Tony Breeds <tony at bakeyournoodle.com> wrote:
> > On Mon, Jun 27, 2016 at 11:28:47PM +0000, Jeremy Stanley wrote:
> >
> >> I want to say there was a reason we were branching the requirements
> >> repo last, but now I can't remember what it is (or if we even did
> >> branch it last). Thierry or Doug likely recall but are indisposed
> >> this week so I suggest waiting until they're around to reply before
> >> making a decision on this anyway (especially since it's the Release
> >> Managers who will need to adjust that process if it does merit
> >> changing).
> 
> I don't remember the specifics, but I had a chat about this some time
> ago, and concur.  As well, requirements branched a couple weeks after
> both Nova and Neutron this time around, I didn't check any others.

Looking back at my mitaka notes, it appears we scheduled the branch
for the requirements repo for the RC1 week, but then put it off
because we wanted to wait until all of the branches for the managed
projects had been created, so we took care of it the following week.
That matches the ~1 week difference between the .gitreview update for
openstack/nova and openstack/requirements.

> Regardless, I don't think there is any way to make a compelling
> argument that the constraints URL should ever dictate when
> the reqs repo should be branched, even if there weren't current
> restrictions to this.
> 
> > I'm not certain how this is different to updating .gitreview and the default
> > branch?  Can't we extend the tools[1] that do that step with the updating of
> > tox.ini?
> 
> I initially had the same thought as Jeremy here, forgetting it could sit in
> review on the stable branch.  While having it sit in the queue and needing
> to be manually checked if it can be merged yet is sub-optimal, I think that
> is probably the best option so far.  The commit message could contain
> details as to the limitations/a link to documentation.

Yes, I think updating that branching script is the best course.

We might want to modify the tox.ini to make it easier to edit with
sed by defining a variable for the branch. It would be nice if we
could just read the value from the .gitreview file, but that might
be trickier than we want to be. The script that creates the branches
is:
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/make_stable_branch.sh

> 
> > It could be worked around with
> > additional logic to fall back on the master URL if the branch
> > doesn't exist, but it's also possible we just document this as a
> > shortcoming for the sake of simplicity.
> 
> This would be wonderful, but I think it would raise the barrier
> to entry on constraints a bit too high and would end up relying
> a bit too much on un-gated code that would mostly be cargo-cult.
> To support this with tox, would require wrapping the tox
> install_command on any project that wishes to use constraints,
> and modifying existing wrapped install_command, which is
> common with the neutron-*aas projects, without any easy way
> to update any of them.
> 
> > OK, lets wait and see what they say.
> 
> Sounds good.
> 
> Cheers,
> Sachi
>