On Mon, May 27, 2019 at 02:48:14PM +0100, Sean Mooney wrote:
The wording there is admittedly confusing: these URLs aren't "wrong", per se, they're just not what we're aiming for going forward. You probably want to look at this email:
http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006478.html
The reason for the -1s is presumably so we can do things correctly now rather than having to fix them again in the future. why would we prefer the release repo over git?
There are a couple of reasons. 1. Using release.o.o allows us is maintain the project state in one location therefore removing a race around branch time. When pointing directly at git the constraints file for $branch doesn't exist until the requirements repo branches. So if $project merges an update to tox.ini pointing that the constraints file for $branch that project on the new stable branch is running without constraints .... Hmm actually this in more nuanced that I have previously understood as I think we might actually be safe in the gate .... I'll look into that. 2. Using releases.o.o allows the requirements team to EOL branches without breaking tox files in git / on pypi. Now clearly neither of these really apply to master, so there it basically comes down to consistency with stable branches where points 1 and 2 make more sense.
i would much prefer if we coninued to use the direct opendev based git urls instead of relying on the redirect as we do here https://github.com/openstack/os-vif/blob/master/tox.ini#L12
https://releases.openstack.org/constraints/upper/master is just a redirect to https://opendev.org/openstack/requirements/raw/branch/master/upper-constrain... which is rather inefficient. would a better soluton to the EOL branches not be dont delete the branch in the first place and just merge a commit declaring it eol.
with extended maintenance i think that makes even more sense now then it did before.
From where I sit, there are lots of things was *can do* and each has pros and cons. None is right or wrong none is the clear winner. Regardless of which we pick there will be knock-on technical impacts. In Sydney, Dublin we had those discussions, in Vancouver we chose to use the tag/delete process. I don't want to sound "ranty" and I don't want to close down a conversation but I also don't want to keep talking about it :/
as a side note in the gate jobs we should also set the UPPER_CONSTRAINTS_FILE env to point a the copy created by the zuul cloner rather then relying on either approch.
Just for clarity s/should also// Redirects aren't used in the gate.
im not going to -1 patches that update to the https://releases.openstack.org/constraints/upper/$series form although i would prefer people do not do it on os-vif until the http{s,}://releases.openstack.org/constraints/upper/master redirect actully use opendev.org as we have already made that switch and i dont want to go form 0 redirects to 2.
So https://review.opendev.org/#/c/660553/ is ready to merge which does this. It has 3 +2's and just didn't get a +W because Friday. I'd expect this to merge "real soon now". As you point out/imply this will take you from 0 to 1 redirect for tox runs outside of the gate. So I'm going to propose the change in os-vif along with all the others. Feel free to add a Depends-On or -W until you're happy with it.
i would like to know why we continue to kill the stable branches for when the go EOL as that is the root of one of the issues raised. Tony do you have insight into that?
The bottom line is that as a whole the community decided at some point we run out of time/energy/resources/spoons to maintain those older branches in the gate and at that point a strong signal for that is desirable. The signal we've chosen is the tag/delete process. The EM policy gives many project teams the ability to make those choices for themselves on a schedule that makes sense to them[1]. In this regard requirements is "just a project"[2] that would like to be able to make that call also.
os-vif's lower constratis job is also not broken in they way that was described in the email so if an automated patch is recived that would regress that ill -2 it and then fix it up.
So the fixing of lower-constraints is being done by hand not a script/tool and I can confirm os-vif isn't in the list of projects that gets an update ;P I do have *other* questions about os-vif's tox.ini, they're totally style related so I'll fire off a change as a place to have that discussion at some stage this week. Yours Tony. [1] Without the general schedule outlined in https://docs.openstack.org/project-team-guide/stable-branches.html [2] Okay it's not "just" a project as it has far reaching impacts when it goes EOL but we're trying to reduce/minimise them and the scope for mistakes.