On Thu, Feb 9, 2012 at 12:57 AM, Robert Collins <robe...@robertcollins.net> wrote: > On Thu, Feb 9, 2012 at 12:49 PM, Guilherme Salgado > <salg...@canonical.com> wrote: >> >> I think that's going to be challenging. My gut reaction would be to look for >> >> 1. Code that's no longer used and can be removed >> 2. Duplicated code which could be moved to a common base >> 3. Code that could be written in a simpler way >> >> Now, just searching for this kind of stuff takes some time, and there >> probably aren't many occurrences of 1 left, so I'd probably focus on 2 >> and 3, which certainly abound, although there's no guarantee that I'll >> have a net negative until after the refactor/rewrite is done. That means >> I may end up spending a day on something just to realize it'll have a >> net negative of a dozen lines or so. That is certainly an improvement to >> Launchpad, but to me (Linaro, in fact) it's mostly wasted effort as it >> didn't take us significantly closer to our goal. > > There is a 4: extract or delete code that shouldn't be part of LP > core. We have a -raft- of 'helpers' (e.g. the thing for running > subprocesses) which are either: > a) uninterestingly different to other helpers on pypi > b) interestingly different but embedded in the LP code base so that > no-one else can use them > c) interestingly different but not pulling their weight > > These things can be pulled out to separate reusable projects, or just > removed entirely and migrated away from. > > and 5: remove code that is used but is a net negative. (e.g. polls) > > In the last week I've seen 2 commits doing (1), one doing (2), and > there is one for (3) about to land. I estimate about 15% of LP is > covered by (4), and another 10%-15% by 5. > > Here are some ideas that should (possibly each on their own) easily > offset your project: > - remove the massive duplication between modules in the blueprints > subsystem; last I checked about 30% of the code in there was verbatim > copies between different contexts. > - move most of utilities/* to the lpdevtools project - thats 6K LOC on its > own > - extract poppy to a separate project (it no longer needs to talk to > the DB, so has no need to be part of LP)
Ditto parts of codehosting. Perhaps the librarian? > - remove polls (not a trivial thing politically, but I'm sure mrevell > is able to clear the way) > - move the ec2 land/test logic to lpdevtools Actually, splitting much of it into its own project would probably be a good idea. We ended up re-implementing a chunk of it, sort of, for pkgme development. > - delete the representation cache from lazr.restful (there is a bug > open for this) > - delete all uses of memcache except for the one for the blog on the front > page And since it's Salgado, we could perhaps add "clean up distribution_mirrorprober & tests". :P > - do the duplicate code part of bug 531720 > - do bug 125637 > - bug 614275 > - bug 706129 > - bug 708736 (should pay for itself via test cleanups) > - bug 888010 > - bug 4449 > > (those bugs come from the first page of tech-debt bugs for launchpad > itself; there may be more if we consider launchpad-project...) I missed this discussion because I'm not particularly interested in migrating blueprint work items from whiteboards (although I think it's a super idea and am glad someone else is doing it). Should there be a wiki page with these ideas, or is the tech-debt tag sufficient? 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
