settingsLogin | Registersettings

Re: [openstack-dev] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini

0 votes

On 2017-09-20 15:19:47 -0400 (-0400), Tony Breeds wrote:

On Wed, Sep 20, 2017 at 06:59:50PM +0000, Jeremy Stanley wrote:

On 2017-09-20 14:46:32 -0400 (-0400), Tony Breeds wrote:
[...]

I'd like to find a solution that doesn't need a tox_install.sh
[...]

This wart came up when discussing Zuul v3 job translations... what
would be ideal is if someone has the bandwidth to work upstream in
tox to add a constraints file option agreeable to its maintainer so
that we don't have to override install-command to add it in all our
configs.

I'm happy to work on it in tox but I don't really have an idea of how to
handle Doug's ideal to avoid having to update the URL for each git
branch.
[...]

Yes, it would help us get rid of ugly wrapper scripts in many
places, but unfortunately doesn't address needing to generate
patches to adjust URLs/filenames.
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

asked Sep 22, 2017 in openstack-dev by Jeremy_Stanley (56,700 points)   3 5 7

8 Responses

0 votes

On Wed, Sep 20, 2017 at 04:51:21PM -0400, Doug Hellmann wrote:
Excerpts from Jeremy Stanley's message of 2017-09-20 18:59:50 +0000:

On 2017-09-20 14:46:32 -0400 (-0400), Tony Breeds wrote:
[...]

I'd like to find a solution that doesn't need a tox_install.sh
[...]

This wart came up when discussing Zuul v3 job translations... what
would be ideal is if someone has the bandwidth to work upstream in
tox to add a constraints file option agreeable to its maintainer so
that we don't have to override install-command to add it in all our
configs.

One of the reasons we need a script is to modify the constraint list to
remove the current library from the list if it is present. I'm not sure
that special logic would be something the tox maintainers would want.

My proposal is that if 'constraints' is enabled then it's only used for
the deps install. Since that should get everything that $project needs
if it's omitted during that phase it wont hurt us and removes the
needs for that aspect of the tox_install.sh

In my head it looks like:


[testenv]
usedevelop = True

constraints = {env:UPPERCONSTRAINTSFILE:https://tarballs.openstack.org/constraints/master.txt}

constraints = {env:UPPERCONSTRAINTSFILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
install_command = pip install {constraints} {opts} {packages}
deps = -r{toxinidir}/requirements.txt
-r{toxinidir}/test-requirements.txt


It wont remove toxinstall.sh but it will reduce the number of projects
that needs it. For example oslso.* and os-* shouldn't need a
tox
install.sh it we can make the above happen.

Yours Tony.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 20, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

Excerpts from Tony Breeds's message of 2017-09-20 17:18:51 -0400:

On Wed, Sep 20, 2017 at 04:51:21PM -0400, Doug Hellmann wrote:

Excerpts from Jeremy Stanley's message of 2017-09-20 18:59:50 +0000:

On 2017-09-20 14:46:32 -0400 (-0400), Tony Breeds wrote:
[...]

I'd like to find a solution that doesn't need a tox_install.sh
[...]

This wart came up when discussing Zuul v3 job translations... what
would be ideal is if someone has the bandwidth to work upstream in
tox to add a constraints file option agreeable to its maintainer so
that we don't have to override install-command to add it in all our
configs.

One of the reasons we need a script is to modify the constraint list to
remove the current library from the list if it is present. I'm not sure
that special logic would be something the tox maintainers would want.

My proposal is that if 'constraints' is enabled then it's only used for
the deps install. Since that should get everything that $project needs
if it's omitted during that phase it wont hurt us and removes the
needs for that aspect of the tox_install.sh

In my head it looks like:


[testenv]
usedevelop = True

constraints = {env:UPPERCONSTRAINTSFILE:https://tarballs.openstack.org/constraints/master.txt}

constraints = {env:UPPERCONSTRAINTSFILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
install_command = pip install {constraints} {opts} {packages}
deps = -r{toxinidir}/requirements.txt
-r{toxinidir}/test-requirements.txt


It wont remove toxinstall.sh but it will reduce the number of projects
that needs it. For example oslso.* and os-* shouldn't need a
tox
install.sh it we can make the above happen.

Yours Tony.

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? If
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.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 20, 2017 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

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.

If
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.

Correct?

Assuming I have that right In the new world:

  1. requirements publish master.txt and series.txt
  2. projects tag RC1 and when generate a stable/series branch.
  3. We generate a reviews that updates .gitreview
  4. We generate a reviews that updates .tox.ini
  5. time passes
  6. requirements creates a stable/series branch
  7. requiremenst now publish series.txt, new_series.txt and master.txt
  8. 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[1] 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.

Yours Tony.

[1] This just occurred to me


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 21, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:

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.

If
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.

Correct?

Assuming I have that right In the new world:

  1. requirements publish master.txt and series.txt
  2. projects tag RC1 and when generate a stable/series branch.
  3. We generate a reviews that updates .gitreview
  4. We generate a reviews that updates .tox.ini
  5. time passes
  6. requirements creates a stable/series branch
  7. requiremenst now publish series.txt, new_series.txt and master.txt
  8. requirements thaws

Where in that sequence do we make the change so that we're not
publishing to series.txt from the new stable branch in requirements and
from master in requirements? Between step 4 and 5? Or is the job smart
enough to not do that?

Where in the sequence do we add new_series.txt? Also between 4 and 5?

In this scenario We've removed the race as there is a series.txt file
available befoer the project and requirements branch.

Also[1] 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.

Yours Tony.

[1] This just occurred to me


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 21, 2017 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

On 17-09-21 12:13:23, Doug Hellmann wrote:
Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:

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.

If
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.

Correct?

Assuming I have that right In the new world:

  1. requirements publish master.txt and series.txt
  2. projects tag RC1 and when generate a stable/series branch.
  3. We generate a reviews that updates .gitreview
  4. We generate a reviews that updates .tox.ini
  5. time passes
  6. requirements creates a stable/series branch
  7. requiremenst now publish series.txt, new_series.txt and master.txt
  8. requirements thaws

Where in that sequence do we make the change so that we're not
publishing to series.txt from the new stable branch in requirements and
from master in requirements? Between step 4 and 5? Or is the job smart
enough to not do that?

Where in the sequence do we add new_series.txt? Also between 4 and 5?

That step of switching from publishing series.txt to new-series.txt
happens in step 6. Step 6 should be dependant on step 5's
patchset/review. The requirements freeze itself hapens some time during
step 4 I think.

In this scenario We've removed the race as there is a series.txt file
available befoer the project and requirements branch.

Also[1] 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.

Yours Tony.

[1] This just occurred to me


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Matthew Thode (prometheanfire)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 21, 2017 by prometheanfire_at_ge (6,880 points)   1 4 5
0 votes

On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:
Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:

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.

If
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.

Correct?

Assuming I have that right In the new world:

  1. requirements publish master.txt and series.txt
  2. projects tag RC1 and when generate a stable/series branch.
  3. We generate a reviews that updates .gitreview
  4. We generate a reviews that updates .tox.ini
  5. time passes
  6. requirements creates a stable/series branch
  7. requiremenst now publish series.txt, new_series.txt and master.txt
  8. requirements thaws

Where in that sequence do we make the change so that we're not
publishing to series.txt from the new stable branch in requirements and
from master in requirements? Between step 4 and 5? Or is the job smart
enough to not do that?

Right now the job is dumb, but yes we'd teach the job to detect that's
it's a stable branch and only publish it's series branch. We also teach
the job to not publish to $series.txt if that stable branch exists.

So I think the publish job looks like:


preamble

typed directly into email so be warned ;P

We probably want to check if ZUUL_BRANCH is the correct variable to

use.

case "$ZUULBRANCH" in
stable/*)
series=$(basename "$ZUUL
BRANCH")
git show origin/$ZUUL_BRANCH:upper-constraints.txt > publish/constraints/upper/${series}.txt
;;
master)
for series in queens master ; do
if ! git rev-parse origin/stable/${series} ; then
git show origin/master:upper-constraints.txt > publish/constraints/upper/${series}.txt
fi
done
;;
esac

postample


So using the queens release as an example:

Jan 22 - Jan 26 R-5 Requirements freeze
NOTES: openstack/requirements (master) publishes {queens,master}.txt
Jan 29 - Feb 02 R-4
Feb 05 - Feb 09 R-3 RC1 target week
ACTIONS: Projects create stable/queens branches
ACTIONS: Generate .gitreview and UPPERCONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER
CONSTRAINTS changes
Feb 12 - Feb 16 R-2
ACTIONS: Projects create stable/queens branch for openstack/requirements
ACTIONS: Generate .gitreview and UPPERCONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER
CONSTRAINTS changes
ACTIONS: Make sure master publishes {rocky,master}.txt
(optionally add the S release at this point, it doesn't hurt)
Feb 19 - Feb 23 R-1
Feb 26 - Mar 02 R+0 Queens release
Mar 05 - Mar 09 R+1
Mar 12 - Mar 16 R+2 Queens cycle-trailing release deadline

There's a whole other side issue about how long requirements is frozen
for. Ignoring that do you think the above process will remove the race,
and mean that EOL branches can possibly continue to run tests?

Yours Tony.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 22, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

Excerpts from Tony Breeds's message of 2017-09-21 20:20:22 -0500:

On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:

Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:

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.

If
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.

Correct?

Assuming I have that right In the new world:

  1. requirements publish master.txt and series.txt
  2. projects tag RC1 and when generate a stable/series branch.
  3. We generate a reviews that updates .gitreview
  4. We generate a reviews that updates .tox.ini
  5. time passes
  6. requirements creates a stable/series branch
  7. requiremenst now publish series.txt, new_series.txt and master.txt
  8. requirements thaws

Where in that sequence do we make the change so that we're not
publishing to series.txt from the new stable branch in requirements and
from master in requirements? Between step 4 and 5? Or is the job smart
enough to not do that?

Right now the job is dumb, but yes we'd teach the job to detect that's
it's a stable branch and only publish it's series branch. We also teach
the job to not publish to $series.txt if that stable branch exists.

So I think the publish job looks like:


preamble

typed directly into email so be warned ;P

We probably want to check if ZUUL_BRANCH is the correct variable to

use.

case "$ZUULBRANCH" in
stable/*)
series=$(basename "$ZUUL
BRANCH")
git show origin/$ZUUL_BRANCH:upper-constraints.txt > publish/constraints/upper/${series}.txt
;;
master)
for series in queens master ; do
if ! git rev-parse origin/stable/${series} ; then
git show origin/master:upper-constraints.txt > publish/constraints/upper/${series}.txt
fi
done
;;
esac

postample


So using the queens release as an example:

Jan 22 - Jan 26 R-5 Requirements freeze
NOTES: openstack/requirements (master) publishes {queens,master}.txt
Jan 29 - Feb 02 R-4
Feb 05 - Feb 09 R-3 RC1 target week
ACTIONS: Projects create stable/queens branches
ACTIONS: Generate .gitreview and UPPERCONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER
CONSTRAINTS changes
Feb 12 - Feb 16 R-2
ACTIONS: Projects create stable/queens branch for openstack/requirements
ACTIONS: Generate .gitreview and UPPERCONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER
CONSTRAINTS changes
ACTIONS: Make sure master publishes {rocky,master}.txt
(optionally add the S release at this point, it doesn't hurt)

We could add new "future" series names as soon as we know them, since we
would just be publishing to a file that nothing uses.

Feb 19 - Feb 23 R-1
Feb 26 - Mar 02 R+0 Queens release
Mar 05 - Mar 09 R+1
Mar 12 - Mar 16 R+2 Queens cycle-trailing release deadline

There's a whole other side issue about how long requirements is frozen
for. Ignoring that do you think the above process will remove the race,
and mean that EOL branches can possibly continue to run tests?

Yours Tony.

Yes, that does look like a sound approach.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 22, 2017 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

On 17-09-22 15:07:14, Doug Hellmann wrote:
Excerpts from Tony Breeds's message of 2017-09-21 20:20:22 -0500:

On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:

Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:

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.

If
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.

Correct?

Assuming I have that right In the new world:

  1. requirements publish master.txt and series.txt
  2. projects tag RC1 and when generate a stable/series branch.
  3. We generate a reviews that updates .gitreview
  4. We generate a reviews that updates .tox.ini
  5. time passes
  6. requirements creates a stable/series branch
  7. requiremenst now publish series.txt, new_series.txt and master.txt
  8. requirements thaws

Where in that sequence do we make the change so that we're not
publishing to series.txt from the new stable branch in requirements and
from master in requirements? Between step 4 and 5? Or is the job smart
enough to not do that?

Right now the job is dumb, but yes we'd teach the job to detect that's
it's a stable branch and only publish it's series branch. We also teach
the job to not publish to $series.txt if that stable branch exists.

So I think the publish job looks like:


preamble

typed directly into email so be warned ;P

We probably want to check if ZUUL_BRANCH is the correct variable to

use.

case "$ZUULBRANCH" in
stable/*)
series=$(basename "$ZUUL
BRANCH")
git show origin/$ZUUL_BRANCH:upper-constraints.txt > publish/constraints/upper/${series}.txt
;;
master)
for series in queens master ; do
if ! git rev-parse origin/stable/${series} ; then
git show origin/master:upper-constraints.txt > publish/constraints/upper/${series}.txt
fi
done
;;
esac

postample


So using the queens release as an example:

Jan 22 - Jan 26 R-5 Requirements freeze
NOTES: openstack/requirements (master) publishes {queens,master}.txt
Jan 29 - Feb 02 R-4
Feb 05 - Feb 09 R-3 RC1 target week
ACTIONS: Projects create stable/queens branches
ACTIONS: Generate .gitreview and UPPERCONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER
CONSTRAINTS changes
Feb 12 - Feb 16 R-2
ACTIONS: Projects create stable/queens branch for openstack/requirements
ACTIONS: Generate .gitreview and UPPERCONSTRAINTS changes
ACTIONS: Projects merge .gitreview and UPPER
CONSTRAINTS changes
ACTIONS: Make sure master publishes {rocky,master}.txt
(optionally add the S release at this point, it doesn't hurt)

We could add new "future" series names as soon as we know them, since we
would just be publishing to a file that nothing uses.

Feb 19 - Feb 23 R-1
Feb 26 - Mar 02 R+0 Queens release
Mar 05 - Mar 09 R+1
Mar 12 - Mar 16 R+2 Queens cycle-trailing release deadline

There's a whole other side issue about how long requirements is frozen
for. Ignoring that do you think the above process will remove the race,
and mean that EOL branches can possibly continue to run tests?

Yours Tony.

Yes, that does look like a sound approach.

Doug

Sounds good, I've created a bug we can start linking reviews to (along
with documenting the final plan).

https://bugs.launchpad.net/openstack-requirements/+bug/1719006

--
Matthew Thode (prometheanfire)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Sep 22, 2017 by prometheanfire_at_ge (6,880 points)   1 4 5
...