• Policy Name: Maintenance

• Policy Owner: Francis Lacoste

• Parent Process/Activity: None

• Supported Policy: None

Policy Overview

Quite separate to adding new features and facilities we have to maintain Launchpad indefinitely. This policy is about containing the costs of maintenance while still allowing Launchpad to be changed and extended.

In short: all changes to Launchpad must decrease, or at worst not increase the overall cost of maintenance.

Maintenance means:

• User support
• Bug triage
• Code review and contribution landings
• operate the site(s)
• fix things that break due to our users using Launchpad
• fix things that break due to external environmental changes (new Ubuntu releases, new browsers releases etc)
• make modest changes based on our bug database as time permits

Experimental metrics

We are using lines of source code as a proxy for all these costs. While this is in some ways a poor metric, it is very simple to apply using the diffstat at the top of our merge proposals.

• thou shalt not increase the LOC count for (the branch 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) needs a waiver from the LP Project lead or CDO Technical architect
  • you have a good claim for reducing non-code costs (e.g. less support tickets) - needs a waiver from the LP Project lead or CDO Technical architect
  • you are moving code to a smaller, leaner and more focused sub-project

  • Non-source boilerplate (e.g. copyright notices) may be ignored if folk can be bothered counting the lines.

  • The LOC count has been offset via an earlier code reduction branch.

The LP Project lead will do a review of the impact of this approach on the 24th of february, then the end of March, then the end of May.

Possible other metrics

• We could use sloccount rather than the simple diffstat counters. This would automatically ignore some boilerplate like copyright notices, but may also ignore doctests (which have code in them.. and often break)
• We could consider using cyclomatic complexity to estimate complexity, and use complexity as a proxy for driving defects

Responsibilities

• code reviewers: Must check that the branch (or a collection of branches - e.g. one cleanup + one feature) meet the LoC metric above.

• other reviewers: Consider the cost of maintenance in your review; be it of usability, feature set, etc... you are expected to think about the cost of maintaining a project and allow for it in some fashion.

This may mean saying 'no' to a volunteer contributed patch because it would increase our maintenance costs. (But you could then offset the cost yourself somewhere else, or ask them to fix e.g. a tech-debt bug to counteract the increased costs).

Prior art

The drizzle project took a very similar approach - they took one metric for maintenance costs/complexity - lines of code - and then used a simple test: patches which increased LoC were highly undesirable. This was very successful for them - they have massively reduced the size of the code base and increased its rate of change.

Why this policy?

Launchpad is resourced with a (mostly) fixed size maintenance team: if the costs of maintenance increase, we will fall behind (with a corresponding decrease in how well we do our maintenance).

Launchpad is currently very expensive to maintain, and we can do much more interesting things if we make it cheap to maintain.

What things affect costs

• The number or difficulty of support tickets
• The number or difficulty of bugs filed against launchpad-project
• Difficulty or time consumption of code review and landing contributions
• difficulty, complexity and resource usage of operating launchpad.net
• Usage of components that do not scale with time / users
• Dependencies on features that are likely to be broken as Ubuntu (our platform) or web browsers (our other platform) evolve
• The amount of code in the system
• The amount of complexity in the system (in any of a number of different ways - more languages, more approaches to doing things, more choice)

XYZ is necessary, but would increase costs, what choices do I have?

• Don't do XYZ
• Pay for XYZ by tackling something that will decrease costs by about the same amount
• Get special dispensation from the Launchpad project leader and/or CDO Technical Architect to increase the maintenance costs

I want to do a bunch of things that will increase costs, but eventually decrease them

Great. Do it - the policy is intended to apply to arc's of work, or stories, not to individual commits. (But sometimes individual commits are the right place to examine such things).

When

The LP Project lead approved this policy on the 10th Feb 2012.

How

Look at the /HitList to get some suggestions on what you could do to offset your contributions.