Greetings all, As the bzr maintainer in EPEL I've been talking to people about updating our bzr version control system stack to the latest version (bzr-2.1.x). The latest version is API incompatible with the current version in EPEL (bzr-1.13) which would normally be frowned upon. In this case, however, there are a few other compatibility concerns that seem to outweigh this:
* The bzr version shipping in Fedora 13 and the Ubuntu Lucid release has some issues when talking to older bzr servers. This means that the new clients on those distributions would be unable to talk to bzr servers using the EPEL-5 packages. Although this is a bug, upstream doesn't yet have a patch for this so it could be quite a while before an update comes out that allows those clients to talk to old servers. * The bzr package in EPEL-5 is not able to talk to launchpad because the on-disk repository format that launchpad uses is not available to the bzr client in EPEL. This means that people running the bzr client we ship in EPEL are not able to share repositories with launchpad, arguably the most important bzr hosting service. The API incompatibility in the bzr package means that when we upgrade, third-party modules could be broken. This involves bzr plugins that are no longer maintained upstream and bzr plugins that may have been written locally to address a local need. Weighed against this is the ability for other third party plugins written and maintained against the current bzr APIs to be built and run once we upgrade. The impression I have and reason that I asked for leave to make this update, was that there are few plugins being used that fall into these categories and that updating to a version of bzr that can work with launchpad, Fedora 13, and the new Ubuntu release are more desirable than breaking these few plugins. If I'm wrong and many of you do depend on the bzr API remaining stable, please speak up so that I don't proceed with this plan. I'll be building updated packages for bzr and the other epel-5 bzr-related packages (bzrtools, bzr-gtk, qbzr, loggerhead) this week and pushing them into epel-testing. They'll sit there for a minimum of two weeks and if there's not an overwhelming outcry that this update should not be performed, they'll then go to the epel-stable repository for all to consume. I hope that we can work to fit the majority of people's needs, -Toshio Kuratomi
pgpyVgmZQjtkf.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
