launchpad-dev team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxxxxx>]

On Sat, Apr 14, 2012 at 11:04:09AM +1200, Robert Collins wrote:
> On Sat, Apr 14, 2012 at 3:37 AM, Jonathan Lange <jml@xxxxxxxxx> wrote:
> >  * improve test suite coverage (I assume this bypasses LoC restrictions?)

When I asked about this, Robert indicated that maintenance costs of the
test suite were a problem too, and so LoC restrictions applied across
the entire codebase, not just to non-tests.

> Colin Watson has been doing a bunch of contributions recently and has
> managed to find LoC improvements to offset his work; perhaps he could
> describe his process for finding such?

Usually the bulk of code I've added has been in tests, so I typically
start by going through the tests and seeing if there's anything obvious
that can be refactored (e.g. r15026.4.2).  Some has been sort of
cheating (compacting unnecessary line breaks and the like), while some
has been more worthwhile (refactoring away unnecessary repetition).

It's worth noting that I've had some feedback that the signal-to-noise
ratio in such branches ... isn't ideal (e.g. spot the actual substantive
changes in r15040), and that the LoC policy applies to arcs of work and
not to single branches, so it's OK to land the cleanups separately.  I
expect I'll do this in future if the cleanups get out of hand.

Other things I've done as an amateur contributor:

 * find and remove unused test data files (e.g. r15040)
 * entirely kill unused scripts/modules (e.g. r15032 - this is easier
   since I'm part of the only team that might ever have used those,
   though, and this is part of a broader months-long arc of work - and
   r15080, which I found by speculative grepping)
 * look for deprecated compatibility wrappers and finish migrations away
   from them (e.g. r15035)
 * look for options that are no longer used (e.g. r15073)

So over the eight branches I've landed since the new policy, I'm at -935
lines in total, and only two of my branches have been net positive.  But
perhaps this is more reflective of the kinds of things I'm doing at the
moment than anything else; I haven't been adding major new features or
anything, so at worst the policy is a minor annoyance for me, and I
don't expect to run seriously afoul of it any time soon.  The major
thing I'm trying to get done is to expose enough API to get rid of all
the archive admin scripts in LP, which is intrinsically likely to reduce
LP's line count.

I rather suspect that in many cases doctest-to-unit-test conversions
would be LoC-negative too, especially some of the really waffly ones
which half-duplicate existing unit tests.

It would be really handy to have something on lpqateam that shows LoC
contributions per contributor (perhaps with some horizon) so that people
have some idea of how much credit they have without having to
laboriously work it out.  It's pretty clear that some things will have
to be traded off and not every single branch can be LoC-negative, so
some kind of simple tracking would be useful.

-- 
Colin Watson                                    [cjwatson@xxxxxxxxxxxxx]