Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-11-26 Thread Julien Danjou
On Fri, Oct 31 2014, Flavio Percoco wrote:

 Fully agree!

 The more I think about it, the more I'm convinced we should keep py26
 in oslo until EOL Juno. It'll take time, it may be painful but it'll
 be simpler to explain and more importantly it'll be simpler to do.

 Keeping this simple will also help us with welcoming more reviewers in
 our team. It's already complex enough to explain what oslo-inc is and
 why there are oslo libraries.

Ok, so now that I start looking into that, it seems nobody added back
Python 2.6 jobs to the Oslo libraries, so they are not gated against it
and the door is open to breakage support.

I'm gonna work on this.

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-11-26 Thread Andreas Jaeger
On 11/26/2014 10:46 AM, Julien Danjou wrote:
 On Fri, Oct 31 2014, Flavio Percoco wrote:
 
 Fully agree!

 The more I think about it, the more I'm convinced we should keep py26
 in oslo until EOL Juno. It'll take time, it may be painful but it'll
 be simpler to explain and more importantly it'll be simpler to do.

 Keeping this simple will also help us with welcoming more reviewers in
 our team. It's already complex enough to explain what oslo-inc is and
 why there are oslo libraries.
 
 Ok, so now that I start looking into that, it seems nobody added back
 Python 2.6 jobs to the Oslo libraries, so they are not gated against it
 and the door is open to breakage support.
 
 I'm gonna work on this.

The libraries have 2.6 support enabled as discussed - but if indeed some
are missing, please send patches,

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-11-26 Thread Julien Danjou
On Wed, Nov 26 2014, Andreas Jaeger wrote:

 The libraries have 2.6 support enabled as discussed - but if indeed some
 are missing, please send patches,

So to recap, it seems to me the plan is to keep all Oslo lib with
Python 2.6 so we don't have any transient dependency problem with stable
in the future. In this regard patch
https://review.openstack.org/#/c/130444 seems to be in contradiction
with what has been decided, I wonder why it has been merged?

I pushed https://review.openstack.org/#/c/137321/ to bring it back.

Please people make up your mind. ;)

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-11-26 Thread Andreas Jaeger
On 11/26/2014 02:48 PM, Julien Danjou wrote:
 On Wed, Nov 26 2014, Andreas Jaeger wrote:
 
 The libraries have 2.6 support enabled as discussed - but if indeed some
 are missing, please send patches,
 
 So to recap, it seems to me the plan is to keep all Oslo lib with
 Python 2.6 so we don't have any transient dependency problem with stable
 in the future. In this regard patch
 https://review.openstack.org/#/c/130444 seems to be in contradiction
 with what has been decided, I wonder why it has been merged?

Check the dates when it was proposed. That was based on the initial
proposal, the discussion to use 2.6 everywhere was only done afterwards.

 I pushed https://review.openstack.org/#/c/137321/ to bring it back.
 
 Please people make up your mind. ;)

Thanks for the patch,

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-11-26 Thread Ben Nemec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/26/2014 07:48 AM, Julien Danjou wrote:
 On Wed, Nov 26 2014, Andreas Jaeger wrote:
 
 The libraries have 2.6 support enabled as discussed - but if
 indeed some are missing, please send patches,
 
 So to recap, it seems to me the plan is to keep all Oslo lib with 
 Python 2.6 so we don't have any transient dependency problem with
 stable in the future. In this regard patch 
 https://review.openstack.org/#/c/130444 seems to be in
 contradiction with what has been decided, I wonder why it has been
 merged?
 
 I pushed https://review.openstack.org/#/c/137321/ to bring it
 back.
 
 Please people make up your mind. ;)
 

Heh, we need a tooz lock to prevent us from changing our minds while
patches are in flight. ;-)

Thanks for taking care of this.

- -Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdgvJAAoJEDehGd0Fy7uqbwsH/20xVKHJ2TpVY7usl5DfDTAq
KiVJmqU1TLdyFOrYA0V7VS+zJFrOBep8ZeUeoEBpnruoQyFaniC8LtAKWUSZ8XPC
DlZxYMJKLjToFsQMEvw8wpkLf5eqPpBuAORndleABEuFpNeT6HTu3b2oBxaU+Mps
sy5UZ2mb2sNDJvcKJuOwvCNCzJ6a//4MQVeBekSRUZ/xCxpjoyWH04FmFFGbRZEJ
rZYiTXpV6wukPoRoa+cmaI0LywdbuAWO9vczExvA9FsnYxuxNIJgFcIJvFqnjkEU
5EkchUcXQciCX+hYNxTiSUqxoUddQ/W48EnPhRV7UqYBJc87VcrvOg7aJoAwUv0=
=FJqY
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-31 Thread Flavio Percoco

On 30/10/14 12:25 -0500, Ben Nemec wrote:

On 10/23/2014 04:18 PM, Doug Hellmann wrote:


On Oct 23, 2014, at 2:56 AM, Flavio Percoco fla...@redhat.com wrote:


On 10/22/2014 08:15 PM, Doug Hellmann wrote:

The application projects are dropping python 2.6 support during Kilo, and I’ve 
had several people ask recently about what this means for Oslo. Because we 
create libraries that will be used by stable versions of projects that still 
need to run on 2.6, we are going to need to maintain support for 2.6 in Oslo 
until Juno is no longer supported, at least for some of our projects. After 
Juno’s support period ends we can look again at dropping 2.6 support in all of 
the projects.


I think these rules cover all of the cases we have:

1. Any Oslo library in use by an API client that is used by a supported stable 
branch (Icehouse and Juno) needs to keep 2.6 support.

2. If a client library needs a library we graduate from this point forward, we 
will need to ensure that library supports 2.6.

3. Any Oslo library used directly by a supported stable branch of an 
application needs to keep 2.6 support.

4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one of 
the previous rules applies.

5. The stable/icehouse and stable/juno branches of the incubator need to retain 
2.6 support for as long as those versions are supported.

6. The master branch of the incubator needs to retain 2.6 support until we 
graduate all of the modules that will go into libraries used by clients.


A few examples:

- oslo.utils was graduated during Juno and is used by some of the client 
libraries, so it needs to maintain python 2.6 support.

- oslo.config was graduated several releases ago and is used directly by the 
stable branches of the server projects, so it needs to maintain python 2.6 
support.

- oslo.log is being graduated in Kilo and is not yet in use by any projects, so 
it does not need python 2.6 support.

- oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but 
both are used by client projects, so they need to keep python 2.6 support. At 
that point we can evaluate the code that remains in the incubator and see if 
we’re ready to turn of 2.6 support there.


Let me know if you have questions about any specific cases not listed in the 
examples.


The rules look ok to me but I'm a bit worried that we might miss
something in the process due to all these rules being in place. Would it
be simpler to just say we'll keep py2.6 support in oslo for Kilo and
drop it in Igloo (or L?) ?


I think we have to actually wait for M, don’t we (K  L represents 1 year where 
J is supported, M is the first release where J is not supported and 2.6 can be 
fully dropped).

But to your point of keeping it simple and saying we support 2.6 in all of Oslo 
until no stable branches use it, that could work. I think in practice we’re not 
in any hurry to drop the 2.6 tests from existing Oslo libs, and we just won’t 
add them to new ones, which gives us basically the same result.


A bit late to this discussion, but if we don't add py26 jobs to new
libraries, we need to be very careful that they never get pulled in as a
transitive dep to an existing lib that does need py26 support.  Since I
think some of the current libs are still using incubator modules, it's
possible this could happen as we transition to newly released libs.

So if we're going for safe and simple, we should probably also keep py26
jobs for everything until EOL for Juno.


Fully agree!

The more I think about it, the more I'm convinced we should keep py26
in oslo until EOL Juno. It'll take time, it may be painful but it'll
be simpler to explain and more importantly it'll be simpler to do.

Keeping this simple will also help us with welcoming more reviewers in
our team. It's already complex enough to explain what oslo-inc is and
why there are oslo libraries.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


pgpDMxnup6ePq.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-31 Thread Jeremy Stanley
On 2014-10-31 13:50:25 +1300 (+1300), Robert Collins wrote:
 Actually no - because of pip install, we need to keep support up until
 we can tell folk we don't support them anymore, which is after the
 last point release, not at it. If we drop support earlier, we can't
 release the support dropping versions until the support period ends,
 and that means we'd have an unreleasable trunk, which is bad.

Well, the support-dropping versions of the servers will already be
long-released before the point releases for previous stable branches
peter out... but I get what you're saying. To mitigate we should
force new releases of all dependent clients/libs immediately prior
to dropping Python 2.6 support too.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-30 Thread Ben Nemec
On 10/23/2014 04:18 PM, Doug Hellmann wrote:
 
 On Oct 23, 2014, at 2:56 AM, Flavio Percoco fla...@redhat.com wrote:
 
 On 10/22/2014 08:15 PM, Doug Hellmann wrote:
 The application projects are dropping python 2.6 support during Kilo, and 
 I’ve had several people ask recently about what this means for Oslo. 
 Because we create libraries that will be used by stable versions of 
 projects that still need to run on 2.6, we are going to need to maintain 
 support for 2.6 in Oslo until Juno is no longer supported, at least for 
 some of our projects. After Juno’s support period ends we can look again at 
 dropping 2.6 support in all of the projects.


 I think these rules cover all of the cases we have:

 1. Any Oslo library in use by an API client that is used by a supported 
 stable branch (Icehouse and Juno) needs to keep 2.6 support.

 2. If a client library needs a library we graduate from this point forward, 
 we will need to ensure that library supports 2.6.

 3. Any Oslo library used directly by a supported stable branch of an 
 application needs to keep 2.6 support.

 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one 
 of the previous rules applies.

 5. The stable/icehouse and stable/juno branches of the incubator need to 
 retain 2.6 support for as long as those versions are supported.

 6. The master branch of the incubator needs to retain 2.6 support until we 
 graduate all of the modules that will go into libraries used by clients.


 A few examples:

 - oslo.utils was graduated during Juno and is used by some of the client 
 libraries, so it needs to maintain python 2.6 support.

 - oslo.config was graduated several releases ago and is used directly by 
 the stable branches of the server projects, so it needs to maintain python 
 2.6 support.

 - oslo.log is being graduated in Kilo and is not yet in use by any 
 projects, so it does not need python 2.6 support.

 - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but 
 both are used by client projects, so they need to keep python 2.6 support. 
 At that point we can evaluate the code that remains in the incubator and 
 see if we’re ready to turn of 2.6 support there.


 Let me know if you have questions about any specific cases not listed in 
 the examples.

 The rules look ok to me but I'm a bit worried that we might miss
 something in the process due to all these rules being in place. Would it
 be simpler to just say we'll keep py2.6 support in oslo for Kilo and
 drop it in Igloo (or L?) ?
 
 I think we have to actually wait for M, don’t we (K  L represents 1 year 
 where J is supported, M is the first release where J is not supported and 2.6 
 can be fully dropped).
 
 But to your point of keeping it simple and saying we support 2.6 in all of 
 Oslo until no stable branches use it, that could work. I think in practice 
 we’re not in any hurry to drop the 2.6 tests from existing Oslo libs, and we 
 just won’t add them to new ones, which gives us basically the same result.

A bit late to this discussion, but if we don't add py26 jobs to new
libraries, we need to be very careful that they never get pulled in as a
transitive dep to an existing lib that does need py26 support.  Since I
think some of the current libs are still using incubator modules, it's
possible this could happen as we transition to newly released libs.

So if we're going for safe and simple, we should probably also keep py26
jobs for everything until EOL for Juno.

 
 Doug
 

 Once Igloo development begins, Kilo will be stable (without py2.6
 support except for Oslo) and Juno will be in security maintenance (with
 py2.6 support).

 I guess the TL;DR of what I'm proposing is to keep 2.6 support in oslo
 until we move the rest of the projects just to keep the process simpler.
 Probably longer but hopefully simpler.

 I'm sure I'm missing something so please, correct me here.
 Flavio


 -- 
 @flaper87
 Flavio Percoco

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-30 Thread Robert Collins
On 24 October 2014 13:14, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2014-10-23 17:18:04 -0400 (-0400), Doug Hellmann wrote:
 I think we have to actually wait for M, don’t we (K  L represents
 1 year where J is supported, M is the first release where J is not
 supported and 2.6 can be fully dropped).
 [...]

 Roughly speaking, probably. It's more accurate to say we need to
 keep it until stable/juno reaches end of support, which won't
 necessarily coincide exactly with any particular release cycle
 ending (it will instead coincide with whenever the stable branch
 management team decides the final 2014.2.x point release is, which I
 don't think has been settled quite yet).

Actually no - because of pip install, we need to keep support up until
we can tell folk we don't support them anymore, which is after the
last point release, not at it. If we drop support earlier, we can't
release the support dropping versions until the support period ends,
and that means we'd have an unreleasable trunk, which is bad.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-24 Thread Flavio Percoco
On 10/24/2014 02:14 AM, Jeremy Stanley wrote:
 On 2014-10-23 17:18:04 -0400 (-0400), Doug Hellmann wrote:
 I think we have to actually wait for M, don’t we (K  L represents
 1 year where J is supported, M is the first release where J is not
 supported and 2.6 can be fully dropped).
 [...]
 
 Roughly speaking, probably. It's more accurate to say we need to
 keep it until stable/juno reaches end of support, which won't
 necessarily coincide exactly with any particular release cycle
 ending (it will instead coincide with whenever the stable branch
 management team decides the final 2014.2.x point release is, which I
 don't think has been settled quite yet).
 

Agreed! I think this is a safer and easier way to drop support for py26
in Oslo. Otherwise, I think we'll have to fight with backports, pinned
versions and whatnot.

Thoughts?
Flavio

-- 
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-24 Thread Doug Hellmann

On Oct 23, 2014, at 8:14 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2014-10-23 17:18:04 -0400 (-0400), Doug Hellmann wrote:
 I think we have to actually wait for M, don’t we (K  L represents
 1 year where J is supported, M is the first release where J is not
 supported and 2.6 can be fully dropped).
 [...]
 
 Roughly speaking, probably. It's more accurate to say we need to
 keep it until stable/juno reaches end of support, which won't
 necessarily coincide exactly with any particular release cycle
 ending (it will instead coincide with whenever the stable branch
 management team decides the final 2014.2.x point release is, which I
 don't think has been settled quite yet).

Good point. I’ve been conflating those two things, but they are separate events.

Doug


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Flavio Percoco
On 10/22/2014 08:15 PM, Doug Hellmann wrote:
 The application projects are dropping python 2.6 support during Kilo, and 
 I’ve had several people ask recently about what this means for Oslo. Because 
 we create libraries that will be used by stable versions of projects that 
 still need to run on 2.6, we are going to need to maintain support for 2.6 in 
 Oslo until Juno is no longer supported, at least for some of our projects. 
 After Juno’s support period ends we can look again at dropping 2.6 support in 
 all of the projects.
 
 
 I think these rules cover all of the cases we have:
 
 1. Any Oslo library in use by an API client that is used by a supported 
 stable branch (Icehouse and Juno) needs to keep 2.6 support.
 
 2. If a client library needs a library we graduate from this point forward, 
 we will need to ensure that library supports 2.6.
 
 3. Any Oslo library used directly by a supported stable branch of an 
 application needs to keep 2.6 support.
 
 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one of 
 the previous rules applies.
 
 5. The stable/icehouse and stable/juno branches of the incubator need to 
 retain 2.6 support for as long as those versions are supported.
 
 6. The master branch of the incubator needs to retain 2.6 support until we 
 graduate all of the modules that will go into libraries used by clients.
 
 
 A few examples:
 
 - oslo.utils was graduated during Juno and is used by some of the client 
 libraries, so it needs to maintain python 2.6 support.
 
 - oslo.config was graduated several releases ago and is used directly by the 
 stable branches of the server projects, so it needs to maintain python 2.6 
 support.
 
 - oslo.log is being graduated in Kilo and is not yet in use by any projects, 
 so it does not need python 2.6 support.
 
 - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but 
 both are used by client projects, so they need to keep python 2.6 support. At 
 that point we can evaluate the code that remains in the incubator and see if 
 we’re ready to turn of 2.6 support there.
 
 
 Let me know if you have questions about any specific cases not listed in the 
 examples.

The rules look ok to me but I'm a bit worried that we might miss
something in the process due to all these rules being in place. Would it
be simpler to just say we'll keep py2.6 support in oslo for Kilo and
drop it in Igloo (or L?) ?

Once Igloo development begins, Kilo will be stable (without py2.6
support except for Oslo) and Juno will be in security maintenance (with
py2.6 support).

I guess the TL;DR of what I'm proposing is to keep 2.6 support in oslo
until we move the rest of the projects just to keep the process simpler.
Probably longer but hopefully simpler.

I'm sure I'm missing something so please, correct me here.
Flavio


-- 
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Andreas Jaeger
Doug, thanks for writing this up.

Looking at your list, I created a patch and only changed oslo.log:

https://review.openstack.org/130444

Please double check that I didn't miss anything,

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Flavio Percoco
On 10/23/2014 08:56 AM, Flavio Percoco wrote:
 On 10/22/2014 08:15 PM, Doug Hellmann wrote:
 The application projects are dropping python 2.6 support during Kilo, and 
 I’ve had several people ask recently about what this means for Oslo. Because 
 we create libraries that will be used by stable versions of projects that 
 still need to run on 2.6, we are going to need to maintain support for 2.6 
 in Oslo until Juno is no longer supported, at least for some of our 
 projects. After Juno’s support period ends we can look again at dropping 2.6 
 support in all of the projects.


 I think these rules cover all of the cases we have:

 1. Any Oslo library in use by an API client that is used by a supported 
 stable branch (Icehouse and Juno) needs to keep 2.6 support.

 2. If a client library needs a library we graduate from this point forward, 
 we will need to ensure that library supports 2.6.

 3. Any Oslo library used directly by a supported stable branch of an 
 application needs to keep 2.6 support.

 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one 
 of the previous rules applies.

 5. The stable/icehouse and stable/juno branches of the incubator need to 
 retain 2.6 support for as long as those versions are supported.

 6. The master branch of the incubator needs to retain 2.6 support until we 
 graduate all of the modules that will go into libraries used by clients.


 A few examples:

 - oslo.utils was graduated during Juno and is used by some of the client 
 libraries, so it needs to maintain python 2.6 support.

 - oslo.config was graduated several releases ago and is used directly by the 
 stable branches of the server projects, so it needs to maintain python 2.6 
 support.

 - oslo.log is being graduated in Kilo and is not yet in use by any projects, 
 so it does not need python 2.6 support.

 - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but 
 both are used by client projects, so they need to keep python 2.6 support. 
 At that point we can evaluate the code that remains in the incubator and see 
 if we’re ready to turn of 2.6 support there.


 Let me know if you have questions about any specific cases not listed in the 
 examples.
 
 The rules look ok to me but I'm a bit worried that we might miss
 something in the process due to all these rules being in place. Would it
 be simpler to just say we'll keep py2.6 support in oslo for Kilo and
 drop it in Igloo (or L?) ?
 
 Once Igloo development begins, Kilo will be stable (without py2.6
 support except for Oslo) and Juno will be in security maintenance (with
 py2.6 support).

OMFG, did I really say Igloo? I should really consider taking a break.
Anyway, just read Igloo as the L release.

Seriously, WTF?
Flavio

 
 I guess the TL;DR of what I'm proposing is to keep 2.6 support in oslo
 until we move the rest of the projects just to keep the process simpler.
 Probably longer but hopefully simpler.
 
 I'm sure I'm missing something so please, correct me here.
 Flavio
 
 


-- 
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Andrey Kurilin
Just a joke: Can we drop supporting Python 2.6, when several project still
have hooks for Python 2.4?

https://github.com/openstack/python-novaclient/blob/master/novaclient/exceptions.py#L195-L203
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/exceptions.py#L147-L155

On Wed, Oct 22, 2014 at 9:15 PM, Doug Hellmann d...@doughellmann.com
wrote:

 The application projects are dropping python 2.6 support during Kilo, and
 I’ve had several people ask recently about what this means for Oslo.
 Because we create libraries that will be used by stable versions of
 projects that still need to run on 2.6, we are going to need to maintain
 support for 2.6 in Oslo until Juno is no longer supported, at least for
 some of our projects. After Juno’s support period ends we can look again at
 dropping 2.6 support in all of the projects.


 I think these rules cover all of the cases we have:

 1. Any Oslo library in use by an API client that is used by a supported
 stable branch (Icehouse and Juno) needs to keep 2.6 support.

 2. If a client library needs a library we graduate from this point
 forward, we will need to ensure that library supports 2.6.

 3. Any Oslo library used directly by a supported stable branch of an
 application needs to keep 2.6 support.

 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one
 of the previous rules applies.

 5. The stable/icehouse and stable/juno branches of the incubator need to
 retain 2.6 support for as long as those versions are supported.

 6. The master branch of the incubator needs to retain 2.6 support until we
 graduate all of the modules that will go into libraries used by clients.


 A few examples:

 - oslo.utils was graduated during Juno and is used by some of the client
 libraries, so it needs to maintain python 2.6 support.

 - oslo.config was graduated several releases ago and is used directly by
 the stable branches of the server projects, so it needs to maintain python
 2.6 support.

 - oslo.log is being graduated in Kilo and is not yet in use by any
 projects, so it does not need python 2.6 support.

 - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo,
 but both are used by client projects, so they need to keep python 2.6
 support. At that point we can evaluate the code that remains in the
 incubator and see if we’re ready to turn of 2.6 support there.


 Let me know if you have questions about any specific cases not listed in
 the examples.

 Doug

 PS - Thanks to fungi and clarkb for helping work out the rules above.
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Kevin L. Mitchell
On Thu, 2014-10-23 at 18:56 +0300, Andrey Kurilin wrote:
 Just a joke: Can we drop supporting Python 2.6, when several project
 still have hooks for Python 2.4?
 
 https://github.com/openstack/python-novaclient/blob/master/novaclient/exceptions.py#L195-L203
 https://github.com/openstack/python-cinderclient/blob/master/cinderclient/exceptions.py#L147-L155

It may have been intended as a joke, but it's worth pointing out that
the Xen plugins for nova (at least) have to be compatible with Python
2.4, because they run on the Xenserver, which has an antiquated Python
installed :)

As for the clients, we could probably drop that segment now; it's not
like we *test* against 2.4, right?  :)
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com
Rackspace


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Doug Hellmann

On Oct 23, 2014, at 2:56 AM, Flavio Percoco fla...@redhat.com wrote:

 On 10/22/2014 08:15 PM, Doug Hellmann wrote:
 The application projects are dropping python 2.6 support during Kilo, and 
 I’ve had several people ask recently about what this means for Oslo. Because 
 we create libraries that will be used by stable versions of projects that 
 still need to run on 2.6, we are going to need to maintain support for 2.6 
 in Oslo until Juno is no longer supported, at least for some of our 
 projects. After Juno’s support period ends we can look again at dropping 2.6 
 support in all of the projects.
 
 
 I think these rules cover all of the cases we have:
 
 1. Any Oslo library in use by an API client that is used by a supported 
 stable branch (Icehouse and Juno) needs to keep 2.6 support.
 
 2. If a client library needs a library we graduate from this point forward, 
 we will need to ensure that library supports 2.6.
 
 3. Any Oslo library used directly by a supported stable branch of an 
 application needs to keep 2.6 support.
 
 4. Any Oslo library graduated during Kilo can drop 2.6 support, unless one 
 of the previous rules applies.
 
 5. The stable/icehouse and stable/juno branches of the incubator need to 
 retain 2.6 support for as long as those versions are supported.
 
 6. The master branch of the incubator needs to retain 2.6 support until we 
 graduate all of the modules that will go into libraries used by clients.
 
 
 A few examples:
 
 - oslo.utils was graduated during Juno and is used by some of the client 
 libraries, so it needs to maintain python 2.6 support.
 
 - oslo.config was graduated several releases ago and is used directly by the 
 stable branches of the server projects, so it needs to maintain python 2.6 
 support.
 
 - oslo.log is being graduated in Kilo and is not yet in use by any projects, 
 so it does not need python 2.6 support.
 
 - oslo.cliutils and oslo.apiclient are on the list to graduate in Kilo, but 
 both are used by client projects, so they need to keep python 2.6 support. 
 At that point we can evaluate the code that remains in the incubator and see 
 if we’re ready to turn of 2.6 support there.
 
 
 Let me know if you have questions about any specific cases not listed in the 
 examples.
 
 The rules look ok to me but I'm a bit worried that we might miss
 something in the process due to all these rules being in place. Would it
 be simpler to just say we'll keep py2.6 support in oslo for Kilo and
 drop it in Igloo (or L?) ?

I think we have to actually wait for M, don’t we (K  L represents 1 year where 
J is supported, M is the first release where J is not supported and 2.6 can be 
fully dropped).

But to your point of keeping it simple and saying we support 2.6 in all of Oslo 
until no stable branches use it, that could work. I think in practice we’re not 
in any hurry to drop the 2.6 tests from existing Oslo libs, and we just won’t 
add them to new ones, which gives us basically the same result.

Doug

 
 Once Igloo development begins, Kilo will be stable (without py2.6
 support except for Oslo) and Juno will be in security maintenance (with
 py2.6 support).
 
 I guess the TL;DR of what I'm proposing is to keep 2.6 support in oslo
 until we move the rest of the projects just to keep the process simpler.
 Probably longer but hopefully simpler.
 
 I'm sure I'm missing something so please, correct me here.
 Flavio
 
 
 -- 
 @flaper87
 Flavio Percoco
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Doug Hellmann

On Oct 23, 2014, at 12:30 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com 
wrote:

 On Thu, 2014-10-23 at 18:56 +0300, Andrey Kurilin wrote:
 Just a joke: Can we drop supporting Python 2.6, when several project
 still have hooks for Python 2.4?
 
 https://github.com/openstack/python-novaclient/blob/master/novaclient/exceptions.py#L195-L203
 https://github.com/openstack/python-cinderclient/blob/master/cinderclient/exceptions.py#L147-L155
 
 It may have been intended as a joke, but it's worth pointing out that
 the Xen plugins for nova (at least) have to be compatible with Python
 2.4, because they run on the Xenserver, which has an antiquated Python
 installed :)
 
 As for the clients, we could probably drop that segment now; it's not
 like we *test* against 2.4, right?  :)

I’m not aware of any Oslo code that presents a problem for those plugins. We 
wouldn’t want to cause a problem, but as you say, we don’t have anywhere to 
test 2.4 code. Do you know if the Xen driver uses any of the Oslo code?

Doug


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Kevin L. Mitchell
On Thu, 2014-10-23 at 17:19 -0400, Doug Hellmann wrote:
 I’m not aware of any Oslo code that presents a problem for those
 plugins. We wouldn’t want to cause a problem, but as you say, we don’t
 have anywhere to test 2.4 code. Do you know if the Xen driver uses any
 of the Oslo code?

I missed the [oslo] tag in the subject line and was thinking generally;
so no, none of the Xen plugins use anything from oslo, because of the
need to support 2.4.
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com
Rackspace


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] python 2.6 support for oslo libraries

2014-10-23 Thread Jeremy Stanley
On 2014-10-23 17:18:04 -0400 (-0400), Doug Hellmann wrote:
 I think we have to actually wait for M, don’t we (K  L represents
 1 year where J is supported, M is the first release where J is not
 supported and 2.6 can be fully dropped).
[...]

Roughly speaking, probably. It's more accurate to say we need to
keep it until stable/juno reaches end of support, which won't
necessarily coincide exactly with any particular release cycle
ending (it will instead coincide with whenever the stable branch
management team decides the final 2014.2.x point release is, which I
don't think has been settled quite yet).
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev