launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Wed, Feb 1, 2012 at 4:32 PM, 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.
>
> Seeking-feedbackly-yrs.
> Rob

Francis and I just covered this on our weekly 1:1 call.

He likes the policy at a conceptual and concrete level, but has one
specific issue with it: the same thing Jono and others have mentioned
- its entirely impossible to enforce it.

So, we need to find a simple metric which will let folk assess their
own, and their colleagues progress with this goal of ours.

The only one that we have at hand is the lines-of-code metric; for
Launchpad with its many separate components, this would look something
like:
 - thou shalt not increase the LOC count for (the thing you are landing code in)
 - unless your work has been blessed by project lead as being
resourced in some way
   or you are on a resourced arc which will reduce code at the end
(e.g. disclosure)
   or you are going to reduce non code costs (e.g. less support tickets)
 - the 'unless' clause would need a signoff from the LP project lead or TA.
 - For the reusable components of LP, adding code which is being
removed from somewhere else is fine (even if there is some overhead in
it becoming reusable)

Francis is going to make a graph of our Loc counts for everything in
https://launchpad.net/launchpad-project - this should be interesting
even if we don't adopt the policy, or choose a different simple metric
for it.

So - who would be happy (and who would not) with a LOC rule like the one above?

-Rob