On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
I like the idea. I'm not sure why, if the constraints file is only used
for the dependency installation step, we still need tox_install.sh?
Right now that isn't true, when we get something like my idea
implemented we'd still need the tox_install.sh in projects that need
services (not published on pypi) like horizon plugins or neutron stadium
projects. Fixing that issue is a totally different discussion, one I
started at the PTG but I need to let those conversations settle and do
research on wasy to fix that.
that's just to avoid updating the URL when we create branches, I can
live with continuing to do that step if we figure out some other way to
minimize the open race window.
So lets check we're on the same page with the race window point. At the
moment the process looks like:
1. projects tag RC1 and when generate a stable/series branch.
2. We generate a reviews that updates .gitreview
3. We generate a reviews that updates .tox.ini
4. time passes
5. requirements creates a stable/series branch
6. requirements thaws
Now the race is that if projects merge the patch from step 3 before step
5 they're broken (on stable/series) because there isn't a
'stable/series' in the requirements repo. There are some additional issues
for cycle-trailing projects but nothing radically different.
Assuming I have that right In the new world:
- requirements publish master.txt and series.txt
- projects tag RC1 and when generate a stable/series branch.
- We generate a reviews that updates .gitreview
- We generate a reviews that updates .tox.ini
- time passes
- requirements creates a stable/series branch
- requiremenst now publish series.txt, new_series.txt and master.txt
- requirements thaws
In this scenario We've removed the race as there is a series.txt file
available befoer the project and requirements branch.
Also if, right now, projects used queens.txt we wouldn't need to
update tox.ini when we branch stable/queens, but we would need to update
master. This is a point of confusion that we'll need to document and
possible check for somewhere in our tools.
 This just occurred to me
OpenStack Development Mailing List (not for usage questions)