← Back to team overview

launchpad-dev team mailing list archive

Re: mercurial imports (was: proposed policy: maintenance costs)

 

On Fri, May 18, 2012 at 02:40:20PM +0100, Matthew Revell wrote:
> On 17 May 2012 23:45, Jelmer Vernooij <jelmer@xxxxxxxxxxxxx> wrote:
> > It doesn't look like anybody is going to be working on bzr-hg soon.
> > There are 40 working imports versus 170 failing at the moment [1], and
> > a little over a dozen bugs open about it.
> I'd like to talk to the people who requested those 40 successful
> imports but I think we'd gain more in terms of polish and maintenance
> cost reduction by killing Hg imports than we gain from those imports.

They are (in the order that the imports were created):

https://launchpad.net/~jelmer/ (hi!)
https://launchpad.net/~gregor-muellegger
https://launchpad.net/~chazz
https://launchpad.net/~jml
https://launchpad.net/~mwhudson
https://launchpad.net/~vladimir.kolev
https://launchpad.net/~youversion4china-translators
https://launchpad.net/~quartz25
https://launchpad.net/~andrea.corbellini
https://launchpad.net/~russel
https://launchpad.net/~veger
https://launchpad.net/~happyaron
https://launchpad.net/~dialtone
https://launchpad.net/~dns
https://launchpad.net/~ripps818
https://launchpad.net/~lakshmi7977
https://launchpad.net/~djfroofy
https://launchpad.net/~renatosilva
https://launchpad.net/~danilobuzar
https://launchpad.net/~kendfinger
https://launchpad.net/~hrvojes
https://launchpad.net/~lakshmi7977
https://launchpad.net/~stephane-mangin-l

> > I would like to propose removing the existing hg support. I think we
> > should remove rather than disable the hg import code because the
> > existing bzr-hg code is likely to bitrot further (it depends on
> > upstream Mercurial), and there isn't a lot of glue code in
> > Launchpad anyway; we won't save all that much time by keeping it in if
> > we want to reintroduce it later. Marking Mercurial imports as beta
> > doesn't seem reasonable either given only a small minority finishes
> > successfully anymore.
> Yeah, a 23.5% success rate is embarrassing and I agree that slapping a
> beta tag on it would be inappropriate.
It was significantly better when we last discussed marking them beta,
but things seem to've deteriorated quickly since.

> >From a Product Manager PoV, I agree that we should remove Mercurial
> imports but, as I say, I'd like to talk to the 40 lucky winners of the
> import lottery before we do anything, to give them a chance to make
> other arrangements etc.
At the very least, they should be able to use bzr-hg locally. That
should give them the same results as on Launchpad. bzr-hg is no longer
in Ubuntu but installing it should be fairly simple ("bzr branch
lp:bzr-hg ~/.bazaar/plugins/hg").

> > Another reason why I prefer to remove the existing HG support
> > code is that eventually I would like to get rid of the type field in
> > the CodeImport class.  Bazaar has a mechanism for opening a branch -
> > in any format - from a URL, so there isn't really a need for the user
> > to specify the VCS to expect. Bazaar can find it out when it does the
> > import.
> >
> > Doing this has some advantages:
> >
> >  * it makes our UI simpler - users no longer have to choose the
> >   version control system to import from, they just have to fill in a
> >   single URL (perhaps with some javascript help for git branches/CVS
> >   modules)
> >  * it becomes possible to change the type of a CodeImport; at the
> >   moment the existing code import has to be removed and a new one
> >   added
> >  * it makes our code simpler - we can ditch a lot of code that is
> >   specific for svn, git, hg or bzr.
> >  * related to the previous point, this makes it easier to add (or
> >   remove) foreign branch plugins
> 
> Any disadvantages?

* If there are bugs in the probers (the code which checks if a particular
  VCS is present at a URL) we will now be affected by it.
  That said, these bug have been ironed out pretty well over the last
  couple of years because bzr users would hit them.

* It becomes trickier to support different VCS repositories in different
  formats at the same URL. In other words, if a directory has a .git
  and a .bzr subdirectory we would import the Bazaar repository, not
  the git one.

  I haven't actually seen this kind of cohabitation in practice, and
  if it does happen users can always specify git+http://.../ or
  something like that.

Cheers,

Jelmer


References