Open Stack

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.


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.


> 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