Open Stack

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-constraints.txt
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190528/5fc0a094/attachment.sig>