launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Thu, Feb 9, 2012 at 2:30 PM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> On Fri, Feb 10, 2012 at 3:15 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 12-02-08 07:57 PM, Robert Collins wrote:
>>> - move most of utilities/* to the lpdevtools project - thats 6K LOC
>>> on its own
>>
>> If our goal is to reduce maintenance costs, how does moving code from
>> Launchpad to lpdevtools accomplish that?
>
> In general for the moved code:
>  - faster iterations (all tests can be run in shorter timeframes)
>  - better locality of reference when editing it
>  - clearer external contracts / interfaces - the borders are crisper
>
> In general for the tree the code was extracted from:
>  - faster test suite time
>   - can run against a mock of the now formal interface
>   - no longer run tests of the implementation of the interface
>  - More focused code base
>  - May well be able to reuse an existing implementation instead.
>
> Now for lpdevtools itself some of these points are rather weak,
> because it is tools to work on lp rather than the implementation; and
> we've historically got poor testing of our utilities.
> However, we're moving LP to be a collection of heterogeneous services
> and it already is a collection of many source code components; many of
> the tools we have written (e.g. the lint script that takes bzr st into
> account) are very useful for other source trees.
>
> Having one reusable location for [most of] our utility scripts means
> that we don't need to copy/propogate them amongst other components,
> and we don't need to think hard about where to go to find/edit them.
>

FWIW, here's some of the historical reasons for putting stuff in utilities:

 * lower barriers to actually fixing the utilities -- you already have
the code in tree
 * same review & landing process as Launchpad
   * with lpdevutils, it was unclear who needed to review, whether
landing was by submitting to PQM, which PQM to submit to etc.
   * ISTR coding conventions varied too
 * easier end-user support (i.e. fewer branches that LP developers had
to keep up to date. "Pull latest LP stable" is easier than "Pull
latest LP stable and rNN of lpdevutils").

I doubt many of these reasons hold today, but I just wanted to give
the background.

jml