launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Fri, Feb 3, 2012 at 4:53 AM, Matthew Revell
<matthew.revell@xxxxxxxxxxxxx> wrote:
> 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.

Thats a really interesting discussion, and quite related. I don't
propose this new policy *in order* to sharpen focus, but I think a
clearer sense of focus will naturally occur.

We can obviously and trivially delete all features via the argument
that it costs to maintain them; I think to a certain degree we need to
consider *features* an existing cost - and then a discussion can occur
(like the ones we have had already e.g. on the mentoring feature)
about removing it if it is not pulling its weight. The larger, more
high profile, or strategically important the feature, the higher up
the mgmt chain I'd expect a discussion to go :).

I'd expect that we can save a -huge- amount of code simply by getting
rid of duplicate / reimplemented / NIH code, refactoring and so forth.
There are some features crying out for pruning however :)

-Rob