launchpad-dev team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxxxxxx>]

Am 02/02/12 16:53, schrieb Matthew Revell:
> On 1 February 2012 03:32, Robert Collins<robertc@xxxxxxxxxxxxxxxxx>  wrote:
> > Hi, please glance at https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts
> >
> > The basic idea is that we are where we are today because we didn't at
> > any point put a cap on the overheads involved in maintaining
> > Launchpad. The ratio of developer time that goes into maintenance vs
> > delivering new functionality is quite high, and if it continues to
> > grow we may never climb out of the technical-debt hole that we have.
> Thanks for writing this.
>
> In terms of features, it'd be interesting to have a "no feature is
> sacred" mentality. I think we already do, to an extent and that we
> should keep it in mind when considering what we can cut in order to
> reduce maintenance burden.
>
> For example, and only an example, imports from Mercurial have never
> worked particularly well, we don't have time to fix them right now and
> there are fewer than 200 active (around 40 of which are borked)
> imports. That's a pretty easy example but I bet there are other places
> where we can sharpen Launchpad's focus to those things it does well
> and, in doing so, reduce maintenance costs.
Mercurial imports are an interesting case. They are not very reliable at 
the moment though, and that doesn't seem likely to change any time soon. 
  I don't think there is a high maintenance cost to keep them as is (in 
tickets, incidents, etc), but we probably wouldn't want to keep them in 
their current state for long (even if they're useful for some people).

CVS imports seem to be at roughly the same level (382 succeeding, 82 
failing), but they've worked relatively well in the past. Should we be 
considering their cost as well? This would also allow us to drop the 
entire launchpad-cscvs codebase.

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?

Cheers,

Jelmer