settingsLogin | Registersettings

[openstack-dev] [all][ptl][stable][release] stable/pike branches created for most libraries

0 votes

As Thierry mentioned in his countdown email today, the release team has
now created the stable branches for most deliverables with type
"library".

We have 3 exceptions:

  1. python-neutronclient had a late release, so I will be branching it
    shortly.
  2. python-barbicanclient was skipped until they have a chance to resolve
    the critical bug they are working on.
  3. tempest doesn't branch (we should probably reclassify that as
    something other than a library to avoid issues with the automation)

All libraries should have had updates for the .gitreview file in the new
branch, the constraints URL in the tox.ini file, and the reno
configuration (in master, if the project uses reno).

Landing any of the patches in the stable/pike branch will trigger a new
documentation build publishing to docs.o.o/$project/pike.

Please take over any of the bot-created patches that do not pass your
validation jobs and fix them so that they can land as soon as possible.

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
asked Aug 3, 2017 in openstack-dev by Doug_Hellmann (87,520 points)   3 4 9

14 Responses

0 votes

Thanks for the reminder, I saw related patches showed up in the Gerrit,
will ensure them pass validation jobs.

2017-07-29 5:13 GMT+08:00 Doug Hellmann doug@doughellmann.com:

As Thierry mentioned in his countdown email today, the release team has
now created the stable branches for most deliverables with type
"library".

We have 3 exceptions:

  1. python-neutronclient had a late release, so I will be branching it
    shortly.
  2. python-barbicanclient was skipped until they have a chance to resolve
    the critical bug they are working on.
  3. tempest doesn't branch (we should probably reclassify that as
    something other than a library to avoid issues with the automation)

All libraries should have had updates for the .gitreview file in the new
branch, the constraints URL in the tox.ini file, and the reno
configuration (in master, if the project uses reno).

Landing any of the patches in the stable/pike branch will trigger a new
documentation build publishing to docs.o.o/$project/pike.

Please take over any of the bot-created patches that do not pass your
validation jobs and fix them so that they can land as soon as possible.

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

--
ChangBo Guo(gcb)


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 Jul 29, 2017 by ChangBo_Guo (4,540 points)   3 5
0 votes

On 07/28/2017 11:13 PM, Doug Hellmann wrote:
As Thierry mentioned in his countdown email today, the release team has
now created the stable branches for most deliverables with type
"library".

We have 3 exceptions:

  1. python-neutronclient had a late release, so I will be branching it
    shortly.
  2. python-barbicanclient was skipped until they have a chance to resolve
    the critical bug they are working on.
  3. tempest doesn't branch (we should probably reclassify that as
    something other than a library to avoid issues with the automation)

All libraries should have had updates for the .gitreview file in the new
branch, the constraints URL in the tox.ini file, and the reno
configuration (in master, if the project uses reno).

Landing any of the patches in the stable/pike branch will trigger a new
documentation build publishing to docs.o.o/$project/pike.

Please take over any of the bot-created patches that do not pass your
validation jobs and fix them so that they can land as soon as possible.

Just to clarify: we cannot land the tox.ini change until the requirements repo
is actually branched, right?

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


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 Jul 29, 2017 by Dmitry_Tantsur (18,080 points)   2 3 7
0 votes

Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:

On 07/28/2017 11:13 PM, Doug Hellmann wrote:

As Thierry mentioned in his countdown email today, the release team has
now created the stable branches for most deliverables with type
"library".

We have 3 exceptions:

  1. python-neutronclient had a late release, so I will be branching it
    shortly.
  2. python-barbicanclient was skipped until they have a chance to resolve
    the critical bug they are working on.
  3. tempest doesn't branch (we should probably reclassify that as
    something other than a library to avoid issues with the automation)

All libraries should have had updates for the .gitreview file in the new
branch, the constraints URL in the tox.ini file, and the reno
configuration (in master, if the project uses reno).

Landing any of the patches in the stable/pike branch will trigger a new
documentation build publishing to docs.o.o/$project/pike.

Please take over any of the bot-created patches that do not pass your
validation jobs and fix them so that they can land as soon as possible.

Just to clarify: we cannot land the tox.ini change until the requirements repo
is actually branched, right?

Good point. The tests for those patches are passing for some projects in
CI, but when the patches are landed it will make it a little harder for
anyone to run the tests for the branch elsewhere because the
requirements repo has not yet been branched.

So, yes, hold off on landing the constraint URL changes.

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 Jul 31, 2017 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:

Just to clarify: we cannot land the tox.ini change until the requirements repo
is actually branched, right?

Good point. The tests for those patches are passing for some projects in
CI, but when the patches are landed it will make it a little harder for
anyone to run the tests for the branch elsewhere because the
requirements repo has not yet been branched.

So, yes, hold off on landing the constraint URL changes.

I wonder if we should look at publishing the upper-constraints.txt file
somewhere (other than cgit). If we did something like:

tarballs.o.o/constraints/$series.txt

We wouldn't have an issue when we EOL a branch and the url's hard-coded
in tox.ini breaking. queens.txt wouldn't exist until we branch
requirements but we could work around that with a redirect if needed.

Later we could get really crazy and make a version that took a package
name and version perhaps like:

tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py --version)

Which would redirect to the appropriate series file. I think we have
enough data in openstack/releases to generate those redirects. We'd
need to think about projects / repos that don't use the release
infrastructure.

That'd mean we could get way from hard-coding the URLs in tox.ini and
therefore not need to update them at branch time.

I've either had too much coffee or not enough. y'all decide.

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 Aug 3, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

On 2017-08-03 12:43:04 +1000 (+1000), Tony Breeds wrote:
[...]
I wonder if we should look at publishing the upper-constraints.txt file
somewhere (other than cgit). If we did something like:

tarballs.o.o/constraints/$series.txt

We wouldn't have an issue when we EOL a branch and the url's hard-coded
in tox.ini breaking. queens.txt wouldn't exist until we branch
requirements but we could work around that with a redirect if needed.

Later we could get really crazy and make a version that took a package
name and version perhaps like:

tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py --version)

Which would redirect to the appropriate series file. I think we have
enough data in openstack/releases to generate those redirects. We'd
need to think about projects / repos that don't use the release
infrastructure.
[...]

Seems like a fine enough plan, but maybe the releases site is a
better place to publish these in that case?
--
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

responded Aug 3, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

On Thu, Aug 03, 2017 at 02:51:39AM +0000, Jeremy Stanley wrote:
On 2017-08-03 12:43:04 +1000 (+1000), Tony Breeds wrote:
[...]

I wonder if we should look at publishing the upper-constraints.txt file
somewhere (other than cgit). If we did something like:

tarballs.o.o/constraints/$series.txt

We wouldn't have an issue when we EOL a branch and the url's hard-coded
in tox.ini breaking. queens.txt wouldn't exist until we branch
requirements but we could work around that with a redirect if needed.

Later we could get really crazy and make a version that took a package
name and version perhaps like:

tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py --version)

Which would redirect to the appropriate series file. I think we have
enough data in openstack/releases to generate those redirects. We'd
need to think about projects / repos that don't use the release
infrastructure.
[...]

Seems like a fine enough plan, but maybe the releases site is a
better place to publish these in that case?

Yeah probably. I picked tarballs as I started with the data being just
static files that get published more or less like a tarball. ... Then I
had the dynamic idea.

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 Aug 3, 2017 by Tony_Breeds (19,660 points)   3 6 11
0 votes

Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:

On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:

Just to clarify: we cannot land the tox.ini change until the requirements repo
is actually branched, right?

Good point. The tests for those patches are passing for some projects in
CI, but when the patches are landed it will make it a little harder for
anyone to run the tests for the branch elsewhere because the
requirements repo has not yet been branched.

So, yes, hold off on landing the constraint URL changes.

I wonder if we should look at publishing the upper-constraints.txt file
somewhere (other than cgit). If we did something like:

tarballs.o.o/constraints/$series.txt

We wouldn't have an issue when we EOL a branch and the url's hard-coded
in tox.ini breaking. queens.txt wouldn't exist until we branch
requirements but we could work around that with a redirect if needed.

I like the idea of publishing to a branch-specific file that always
stays on the server. We could make the job on master publish both
to a master.txt and a $series.txt file if we need both to exist at the
same time.

Later we could get really crazy and make a version that took a package
name and version perhaps like:

tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py --version)

Which would redirect to the appropriate series file. I think we have
enough data in openstack/releases to generate those redirects. We'd
need to think about projects / repos that don't use the release
infrastructure.

How would that redirect be used?

That'd mean we could get way from hard-coding the URLs in tox.ini and
therefore not need to update them at branch time.

I've either had too much coffee or not enough. y'all decide.

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 Aug 3, 2017 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

On 2017-08-03 17:04, Doug Hellmann wrote:
Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:

On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:

Just to clarify: we cannot land the tox.ini change until the requirements repo
is actually branched, right?

Good point. The tests for those patches are passing for some projects in
CI, but when the patches are landed it will make it a little harder for
anyone to run the tests for the branch elsewhere because the
requirements repo has not yet been branched.

So, yes, hold off on landing the constraint URL changes.

I wonder if we should look at publishing the upper-constraints.txt file
somewhere (other than cgit). If we did something like:

tarballs.o.o/constraints/$series.txt

We wouldn't have an issue when we EOL a branch and the url's hard-coded
in tox.ini breaking. queens.txt wouldn't exist until we branch
requirements but we could work around that with a redirect if needed.

I like the idea of publishing to a branch-specific file that always
stays on the server. We could make the job on master publish both
to a master.txt and a $series.txt file if we need both to exist at the
same time.

this would mean that depends-on does not work anymore - if you update
the upper-constraint file and want to test, you can use depends-on today.

with uploading to tarballs, this will not work,

Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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 Aug 3, 2017 by Andreas_Jaeger (17,140 points)   2 3 4
0 votes

On 2017-08-03 17:33:46 +0200 (+0200), Andreas Jaeger wrote:
[...]
this would mean that depends-on does not work anymore - if you update
the upper-constraint file and want to test, you can use depends-on today.

with uploading to tarballs, this will not work,

I think this is more about the fallback a lot of projects have to
retrieve constraints files from git.openstack.org directly when not
already supplied, as a workaround for being able to use constraints
locally on developers' systems or when deploying software from
source. Jobs in our CI system would still continue to rely on
zuul-cloner to place the constraints file where tox is expecting it
and so Depends-On would remain working the same way it does
presently.
--
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

responded Aug 3, 2017 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

On 2017-08-03 18:03, Jeremy Stanley wrote:
On 2017-08-03 17:33:46 +0200 (+0200), Andreas Jaeger wrote:
[...]

this would mean that depends-on does not work anymore - if you update
the upper-constraint file and want to test, you can use depends-on today.

with uploading to tarballs, this will not work,

I think this is more about the fallback a lot of projects have to
retrieve constraints files from git.openstack.org directly when not
already supplied, as a workaround for being able to use constraints
locally on developers' systems or when deploying software from
source. Jobs in our CI system would still continue to rely on
zuul-cloner to place the constraints file where tox is expecting it
and so Depends-On would remain working the same way it does
presently.

Indeed, if the CI system continues to use zuul-cloner, everything is fine,

Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


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 Aug 3, 2017 by Andreas_Jaeger (17,140 points)   2 3 4
...