On Fri, Mar 09, 2012 at 11:05:05AM +1100, Martin Pool wrote:
> On 15 February 2012 21:39, Jelmer Vernooij <jel...@canonical.com> 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).
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
