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

[Tony Breeds]

On Thu, Aug 03, 2017 at 07:22:15PM -0400, Doug Hellmann wrote:

> OK, I see. I was assuming we would just tie it to series name, and
> that series name could be taken from the .gitreview file or something.
> So the URL calculation would always be done locally, and we wouldn't
> need any sort of redirects.

If that works then so much better.  I thought we couldn't use that as
.gitreview isn't part of an sdist but then again neither is tox.ini and
at the point we're dealing with an sdist then the admin/user/installer
will have had to pass the constraints URL (or not) so it isn't our
problem.

Perhaps all the dynamic stuff is just over-engineering and we can just
do the url calculation locally.
 
> We still need some sort of wrapper for pip, because you're right I
> don't think we can use $() syntax to set the variable in tox.ini.
> Unless maybe we can do some of this with a tox plugin/extension?
> But it seems better to do it by putting a script or something in
> the repo, so a user has fewer things to install to run the tests.
 

 
> Which things do we have that don't use the releases repo but do use
> constraints?

I don't know of any right now, and I'm struggling to come up with a good
way to check.  I was mostly pointing out a scenario that would fail in
that scheme in the hopes that someone could say "Oh that isn't problem
just do $x"  or "Yup that's a deal breaker"

Tony.


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

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

[Tony Breeds]

On Thu, Aug 03, 2017 at 05:33:46PM +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,

As Jeremy pointed out this would just replaces the existing defult URL
in tox.ini the goal would be for everything else to continue as it does
today just with fewer issues.

Yours Tony.


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

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

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-08-04 08:56:17 +1000:
> On Thu, Aug 03, 2017 at 11:04:52AM -0400, 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.
> > 
> > > 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?
> 
> So I admit I typed that email and hit send without a huge amount of
> thought and even though I use a web browser a lot I don't really
> understand how http works but I was thinking about something like:
> 
> on $server probably releases.o.o but that's a detail we can sort out
> later.
> 
> /constraints contains a .htaccess file generated from the data in
> openstack relases that says something like:
> 
> redirect /constratints/nova/14.* to /constrataints/newton.txt
> redirect /constratints/nova/15.* to /constrataints/ocata.txt
> 
> Any unknown versions get  /constratints/master.txt (or queens.txt
> depending on what we do)
> 
> It could be a redirect or a rewrite rule whatever works best
> 
> then the nova tox.ini does something like:
> ${ENV:UPPER_CONSTRAINTS_FILE:https://server/constratins/nova/$(python
> setup.py --version)}
> 
> Now it is probably that direct shell output can't be used like that and
> then the whole thing fails but I hope we can do something like that ...
> even if in the short term we need to use a helper script like we do to
> work around other constraints issues.

OK, I see. I was assuming we would just tie it to series name, and
that series name could be taken from the .gitreview file or something.
So the URL calculation would always be done locally, and we wouldn't
need any sort of redirects.

We still need some sort of wrapper for pip, because you're right I
don't think we can use $() syntax to set the variable in tox.ini.
Unless maybe we can do some of this with a tox plugin/extension?
But it seems better to do it by putting a script or something in
the repo, so a user has fewer things to install to run the tests.

> If that doesn't work /constraints could become a script that looks and
> the path_element and does the same logic.
> 
> Now it's herder with libraries but now that much harder.
> 
> The trick would be for repos that don't use releases and perhaps for
> them in the first instance they need to hard code the serries.

Which things do we have that don't use the releases repo but do use
constraints?

Doug

> 
> > 
> > > 
> > > 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-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Yours Tony.

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

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

[Tony Breeds]

On Thu, Aug 03, 2017 at 11:04:52AM -0400, 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.
> 
> > 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?

So I admit I typed that email and hit send without a huge amount of
thought and even though I use a web browser a lot I don't really
understand how http works but I was thinking about something like:

on $server probably releases.o.o but that's a detail we can sort out
later.

/constraints contains a .htaccess file generated from the data in
openstack relases that says something like:

redirect /constratints/nova/14.* to /constrataints/newton.txt
redirect /constratints/nova/15.* to /constrataints/ocata.txt

Any unknown versions get  /constratints/master.txt (or queens.txt
depending on what we do)

It could be a redirect or a rewrite rule whatever works best

then the nova tox.ini does something like:
${ENV:UPPER_CONSTRAINTS_FILE:https://server/constratins/nova/$(python
setup.py --version)}

Now it is probably that direct shell output can't be used like that and
then the whole thing fails but I hope we can do something like that ...
even if in the short term we need to use a helper script like we do to
work around other constraints issues.

If that doesn't work /constraints could become a script that looks and
the path_element and does the same logic.

Now it's herder with libraries but now that much harder.

The trick would be for repos that don't use releases and perhaps for
them in the first instance they need to hard code the serries.

> 
> > 
> > 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Yours Tony.


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

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

[Andreas Jaeger]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jeremy Stanley]

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


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

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

[Andreas Jaeger]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tony Breeds]

On Thu, Aug 03, 2017 at 02:51:39AM +, 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.


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

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

[Jeremy Stanley]

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


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

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

[Tony Breeds]

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.


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

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

[Doug Hellmann]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dmitry Tantsur]

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[ChangBo Guo]

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 :

> 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev