Merge lp:~cjwatson/launchpad/germinate-all-dev-series into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | William Grant on 2012-01-03 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 14624 |
| Proposed branch: | lp:~cjwatson/launchpad/germinate-all-dev-series |
| Merge into: | lp:launchpad |
| Diff against target: |
348 lines (+162/-47) 2 files modified
lib/lp/archivepublisher/scripts/generate_extra_overrides.py (+58/-38) lib/lp/archivepublisher/tests/test_generate_extra_overrides.py (+104/-9) |
| To merge this branch: | bzr merge lp:~cjwatson/launchpad/germinate-all-dev-series |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| William Grant | code | 2011-12-26 | Approve on 2012-01-03 |
|
Review via email:
|
|||
Commit Message
[r=wgrant][bug=904538] Let cron.germinate handle multiple dev series.
Description of the Change
== Summary ==
My recent refactoring of cron.germinate caused some dogfood-specific problems, because dogfood has multiple Ubuntu distroseries in the DEVELOPMENT or FROZEN states.
== Proposed fix ==
Generate extra overrides for all DEVELOPMENT and FROZEN series, rather than for just one. Log but otherwise ignore any cases where missing seeds would previously have caused us to abort.
This seems like logically the right thing to do, and removes the obstacle to testing this easily on dogfood.
== Implementation details ==
I introduced a simple new CachedDistroSeries class to preserve the current property that most of generate-
== Tests ==
bin/test -vvct generate_
== Demo and Q/A ==
Run cron.germinate on mawson. Given the current state of dogfood's database, it should emit log entries about the lack of seeds for rusty, and generate updated extra override files (in /srv/launchpad.
== lint ==
None.
| Robert Collins (lifeless) wrote : | # |
| Colin Watson (cjwatson) wrote : | # |
Would it be better to just go back to having multiple lists and
iterating over them with zip() (my personal threshold for when I start
thinking about consolidating this kind of thing into a list of classes
seems to be about three, which is why I did it at this point), or is it
worth caching the property for other reasons anyway?
| Colin Watson (cjwatson) wrote : | # |
I played with @cachedproperty and friends a bit. I eventually decided that I wasn't massively keen on relying on the generational cache for correctness rather than just performance, and switching to the stupid cache started to seem like overengineering for the problem at hand. Instead, I just dropped the CachedDistroSeries business and fetched the relevant properties inside the loop over self.series, so we end up with one transaction per series; this should be fine and is IMO much more obviously correct at sight, which I think is valuable.
The point of the DatabaseBlocked

It would be better I think to cache those values in the main
DistroSeries, using e.g. @cachedproperty. Its a little more work to
validate, but centralises the caching.