launchpad-dev team mailing list archive

[Matthew Revell <matthew.revell@xxxxxxxxxxxxx>]

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.

> 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.

>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.

> 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?

-- 
Matthew Revell
Launchpad Product Manager
Canonical

https://launchpad.net/~matthew.revell