On Thu, Feb 9, 2012 at 2:30 PM, Robert Collins <robe...@robertcollins.net> wrote: > On Fri, Feb 10, 2012 at 3:15 AM, Aaron Bentley <aa...@canonical.com> 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 _______________________________________________ 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
