Breaking python2.4 compatibility for bzr-2.4

[Toshio Kuratomi]

Sorry for the late reply, I've been on an extended (and restful!) vacation.

On Wed, Apr 20, 2011 at 04:41:36PM +0200, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This has been discussed a bit in the past, and Martin and I have chatted
> about it a bit recently on IRC. I've personally reached my threshold,
> and would like to break compatibility with python 2.4 for our next
> release (bzr 2.4).
> 
> The big motivations for this are:
> 1) RHEL was the only platform that didn't have python >2.4. It now has
>    RHEL 6 which has python 2.6. And while RHEL5 is going to be
>    supported for something like 100 more years, RHEL5 was originally
>    released in 2007 which probably predates bzr-1.0 (2007-12-14).
> 
>    If someone is running anything like an up-to-date bzr on RHEL5 they
>    are running custom packages. And there are tons of workarounds for
>    them if they must keep RHEL5 and a newer bzr (run the stable 2.3
>    series, install a python version that isn't 5 years old, etc.)
> 
I'm not 100% against switching to a new python version (though it makes my
life harder) but it's better to have actual facts here than to have sarcasm
:-)

* RHEL5 EOL is March 31, 2014
  - RHEL6 has been out since November 10, 2010
  - RHEL major releases require customers to migrate between releases as
    custom code may be broken by the new release (What we as Linux
    enthusiasts have come to expect when migrating between distro versions
    but what RHEL customers do not expect when migrating between RHEL minor
    releases [like 5.5 to 5.6]).  So there's going to be a mix of people
    using RHEL6 and people using RHEL5 for quite a while.

* bzr-2.1.1 is present in the EPEL repositories for RHEL5.  It only has
  three patches which are easy to audit so they aren't heavily customized.
  - I'd be able to update the packages to bzr-2.3.x if the reason were
    compelling (for instance, to get a new repository format).  We had to
    upgrade from a bzr-1.x in EPEL earlier and the compatibility with
    launchpad's repository format argument was compelling for the other EPEL
    maintainers as a reason for making an incompatible upgrade.

* EPEL5 has python26 packages.  Retargeting the bzr package to work with
  that requires more a bit of ongoing work: maintaining a paramiko,
  pycrypto, and pycurl package for python26; forking the bzr, bzrtools,
  other-bzr-plugins spec files from what Fedora uses to use python26
  instead.  It's doable if it becomes necessary, though.

> 
> 5) If we go all the way to python2.6 compatibility we can start looking
>    at doing things to support Python 3.
>    (This is my recommendation, since RHEL6 has python2.6, and I don't
>    think anything else is strictly blocked for python2.5)

I'm replying here even though there was discussion further down thread.

* python-2.6 seems like a good idea from the Linux distributions standpoint
  (since python-2.6 is widespread in Linux distributions).
* python-2.5 doesn't gain us much on the python3 compatibility front whereas
  python-2.6 does give us significant help in that area.
* A more recent version of python defers somewhat the time before we need to
  decide whether we can't live without the features that are present in even
  newer versions of python.

> The main argument that I've seen for keeping 2.4 is that if we introduce
> a new repository format, then we force people that want to use that
> format on their clients to upgrade their server (which could be running
> an old crufty RHEL5 with maybe some new bzr packages to get 2a format
> compatibility.)
> 
> I say, lets cross that bridge when we get there. We can look at
> providing the repo format as a backport to a stable series, or as a
> plugin for older series.
>
I'd be very happy with this solution should it become necessary.

> Or we can honestly say "If you want to run new
> software, install a newer OS", since there *is* a RHEL which is newer
> and supported (non beta) and has the newer python available.
> 
So -- the issue is that individuals can update their machines pretty easily.
Companies cannot due to their in-house requirements to test and "certify"
that their in-house software runs on the new versions of the OS, train their
support staff to take care of issues with the new OS, come up with
a deployment strategy, etc.

The biggest issue I ran across before was that launchpad upgraded to a new
repository format but the client we had in EPEL wasn't able to use that.  So
people running RHEL as their client machines in corporations were unable to
interoperate with launchpad.

Just some things to keep in mind :-)

One other note that is only somewhat related:

RHEL6 officially ships with bzr-2.1.1.  RHEL6 EOL's on November 30, 2017.
If format changes are in the works sometime before the EOL date, let me know
what arguments I can give to try to persuade the RHEL-bzr maintainer that he
should upgrade to a newer bzr version in the next RHEL6 minor release.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110429/56da2076/attachment.pgp>