On Sat, Apr 14, 2012 at 11:04:09AM +1200, Robert Collins wrote: > On Sat, Apr 14, 2012 at 3:37 AM, Jonathan Lange <j...@mumak.net> 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 [cjwat...@canonical.com] _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
