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 <[email protected]> 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
