launchpad-dev team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxxxxx>]

Hi,

My PPA:

  https://launchpad.net/~cjwatson/+archive/launchpad

... contains changes to the germinate package (you can ignore everything
else in that PPA) which will be required in order to land this branch:

  https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate

Could a Launchpad developer review this lot and copy into the Launchpad
PPA?  germinate 2.0 is in precise (or will be once the librarian is
fixed), so no change is needed for that suite.

== Correctness ==

I've run this from a local tree on mawson against the current Packages
and Sources files from cocoplum, and compared the output before and
after.  The only changes were those I expected from this bug-fix:

  * When promoting dependencies from lesser seeds, remove them from the
    lesser seed lists at output time rather than immediately.  This is
    mostly to make it easier to process multiple seed structures, but also
    fixes a long-standing bug where promoted dependencies were only removed
    from a single arbitrary lesser seed rather than from all possible ones.

This has the effect of removing some duplicate entries from the output
(a couple of these result in removal of redundant entries in Task fields
too), but I've hand-checked all of these and they're correct.

== Performance ==

The new version is a little slower on mawson: the relevant part of
cron.germinate (minus calls to lp-query-distro and maintenance-check)
runs in 14m13s (old) 15m34s (new).  These are single-run timings and
mawson isn't the hottest machine, so they probably aren't that reliable,
but to be honest I did expect a little bit of slowdown since the data
structures in the new version are a bit more elaborate.

However, this should not be a long-term problem, as the core logic from
https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate
runs in 7m9s producing identical output, and I'm pretty sure that I've
got something wrong which is making that slower than it needs to be; so
I think it's OK to accept a possible small temporary slowdown in the
cause of making things a lot faster later.

Thanks,

-- 
Colin Watson                                    [cjwatson@xxxxxxxxxxxxx]