launchpad-dev team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxxxxxx>]

On Fri, Mar 09, 2012 at 11:05:05AM +1100, Martin Pool wrote:
> On 15 February 2012 21:39, Jelmer Vernooij <jelmer@xxxxxxxxxxxxx> wrote:
> > There are three things we can do with Mercurial imports:
> >
> >  * Rip them out completely
> >  * Hide them behind a feature flag
> >  * Mark them as beta
> >
> > I'd prefer either hiding them behind a feature flag or marking them as beta.
> > This would make it possible to easily re-enable them later when bzr-hg is
> > improved. The amount of hg-specific code in launchpad is fairly limited (a
> > couple hundred lines of code, most in tests).
> >
> > Thoughts?
> 
> We should do one of these.
> 
> I would rather not rip them out completely.  (I think generally if you
> have code that's not fully baked, but it's hidden from the user, it's
> ok to leave it in place until the moment it gets in the way of someone
> trying to do something else, or it gets so old it's clearly never
> getting finished.)
> 
> I don't mind much whether they're marked beta or removed entirely.
> (It may be that one patch could fairly add feature flags allowing us
> to either beta-flag them or disable them, but perhaps that's
> overcomplicating things.)
> 
> If there are at least some that are working ok, perhaps marking them
> beta would be enough.
> 
> If they're marked beta, perhaps we can say so when you look at the
> branch page for an import, as well as the point you create one.
> Basically the places they might be looking at when they go to file a
> bug, ought to tell them they're in alpha.  If they're removed
> entirely, I suppose there ought to be some way for people to _know_
> that they're gone, rather than spending their time searching around,
> and perhaps that's a reason to have them visibly deprecated rather
> than just gone.  Perhaps they should be badged 'alpha' not 'beta'.
> 
> Whichever it is, there ought to be a blog post about it, which the ui
> can link to.  Dan can help.  Perhaps that post should give a channel
> to constructively express the desire things be improved, eg by
> upvoting existing bugs.
> 
> Overall, I prefer the idea of marking both hg and cvs imports beta.
Perhaps it's to revisit this.

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

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

Thoughts?

Jelmer

[1] bzr-hg hasn't kept up with upstream developments and we haven't disabled
    imports of repositories that have gone away or migrated to other
    systems (read: git).