On Tue, Jun 28, 2016 at 9:38 AM, Tony Breeds <t...@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 __________________________________________________________________________ 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