Discussion/permission to update bzr - epel-devel - Fedora mailing-lists

8 Apr 2010


      I have a bit of a quandry with the bzr package in EPEL  I want to upgrade it
due to compatibility problems but the upgrade brings in abackwards
compatibility problems.  Let me explain::
bzr is a distributed version control system.  The main hosts of bzr
repositories that we care about are launchpad and fedorahosted.org.  People
can, of course run their own repositories.
The version of bzr in EPEL is 1.3.1  The version of bzr in F-12 is 2.0.5.
The version of bzr in F-13/rawhide is bzr-2.1; bzr-2.2 is just around the
corner (so likely going into F-14)
There are three places where compatibility can be broken in the version
control system:
1) The on-disk repository format
2) The on-the-wire protocol between the client and server.
3) The API -- bzr provides a python module on which other tools can be built
as well as plugins to bzr
The repository formats supported by bzr-1.3 are a subset of the formats
supported by 2.1.  This means that there's no backwards incompatibility
concerns with upgrading to bzr-2.1.  But there is a forwards compatibility
issue where repositories on launchpad and in other projects are not usable
with the bzr client we ship.  This is an impetus for upgrading as the
current EPEL clients will not work with launchpad.
The on wire protocol has been upgraded over time.  There are fallbacks so
that, for instance, the bzr-2.0 client is supposed to work with a bzr-1.3
server.  However, there is one or more bugs in the bzr-2.1 client that's
causing it to not work with the 1.3 server.  This means that the Fedora 13
bzr client cannot talk to the server on fedorahosted.  There currently is no
sign of a patch for the problem.
This just leaves the API.  The API of bzr continuously evolved during the
1.x series (and before).  Typically, incompatible changes were announced
with six month lead time and then any compatibility layer was removed.  If
one change was announced in January and another in February, that meant that
June and July would both have incompatible releases.  This deprecation style
was okay for developers as it allowed them six months to port their stuff
forward but was chaos for distributors like us.  A few of us raised the
issue upstream and starting with bzr-2.0 a different style was adopted.
2.x.y contains no incompatible changes when a new .y releases (barring
secuirty holes that can only be plugged with API changes).  The support
cycle of a 2.x release is 6-12 months (1.x and before had a 1 month cycle).
New 2.x releases may break API but the justification needs to be that it
makes things better for the bzrlib API.  This usually means that porting
should be straightforward.
Plugins and code written for bzr that is currently in Fedora and EPEL all
have versions that run on the latest bzr-2.x (2.1).  Of the tools in EPEL,
none of the versions we're carrying (that run on bzr-1.x) are still
supported by upstream.
Tools that are either locally written or not maintained upstream may be
written for bzr-1.x and will not run on bzr newer than the bzr-1.13 that we
have in EPEL ATM.  This is the case with Fedora Infrastructure's use of
bazaar-webserve, for instance.  Upstream development on it has stopped and
it won't run with anything newer than bzr-1.13.  This is something of
a chicken and egg problem, however, as loggerhead, the new bzr web viewer
won't run with bzr-1.13 so there's been no ability to move off of it without
rebuilding the bzr-2.x stack locally (something I'm in the process of doing
since EPEL's bzr server isn't compatible with F-13's client).
Ubuntu Lucid (the upcoming long term service release) is going to ship with
bzr-2.1.x.  Because it is supported for 3 years on the desktop and 5 years
on the server, I'm guessing that they will upgrade to bzr-2.2, 2.3, 2.4, etc
over the lifetime of the product but they could choose to backport fixes to
bzr-2.1 instead.
So what's this mean for us?  It means that I'd like to update EPEL's bzr to
the 2.1 branch.  This breaks API compatibility but it has the following
benefits:
* It brings us over-the-wire compatibility with bzr-2.x
* It brings us repository format compatibility with current bzr-2.x users so
  they can share their repositories with users of the EPEL packages
* It brings us a client that can talk to launchpad, probably the most
  important source of bzr repositories if you're an open source developer.
So what do other people think here?  Is the over-the-wire and
repository-format compatibility issues sufficient to override the API
compatibility issues in this case?  As the maintainer, I definitely believe
so but I await your input.
Thanks,
-Toshio