mirror of
https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu
synced 2025-04-21 16:11:10 +00:00
27ef44e478
The previous code had some issues with respect to how we decided whether to send an email. The age used for calculating when the next mail should be sent was saved as a float rather than an integer; since p-m runs never happen exactly an integer number of days after upload, this results in a cumulative error in the timing of the emails, that is further exacerbated if a particular run is significantly delayed or if p-m infrastructure is down for a period of time. So instead, we now calculate the age at which the most recent email /should have been sent/, and store that in our cache instead of the precise age. There is still a bit of surprising behavior here due to the fact that we use two different 'max_age' values for valid vs. invalid candidate packages: a single package can, over the course of its stay in -proposed, move from being an invalid candidate to being a valid candidate /and back again/ without ever migrating. Such a package will switch back and forth between two sets of calculations based on different starting offsets, causing the ages at which the emails are sent to vary in a non-obvious fashion. However, this will still obey the general principle of "email reminders of decreasing frequency", so I think this is acceptable given that it is still an overall improvement in predictability. LP: #1671468
Britney - Keeps suites installable and up to date
Britney is a program to compute an update of a Debian-based package suite by feeding it updates from (one or more) source-suite(s). A few known use cases:
- Debian uses it to update testing based on unstable
- Ubuntu uses it to update their latest development suite using a "hidden" -proposed-updates suite as source
Britney's primary goal is too keep packages in the target suite installable (e.g. Debian testing) while keeping it up to date with its primary source suite (e.g. Debian unstable).
Quick setup guide
This is a very brief intro to the steps required to setup a Britney instance.
- Copy "britney.conf.template" and edit it to suit your purpose
- If you want Britney to bootstrap your target suite, you probably want to add all architectures to "NEW_ARCHES" and "BREAK_ARCHES" for a few runs
- Create the following files (they can be empty):
- $STATE_DIR/age-policy-dates
- $STATE_DIR/age-policy-urgencies
- $STATE_DIR/rc-bugs-unstable
- $STATE_DIR/rc-bugs-testing
- Run
./britney.py -c $BRITNEY_CONF -v [--dry-run]to test the run - Use the resulting $HEIDI_OUTPUT (or $HEIDI_DELTA_OUTPUT) to update
your target suite.
- With dak,
cut -d" " -f1-3 < ${HEIDI_OUTPUT} | dak control-suite --set ${TARGET_SUITE} [--britney]
- With dak,
- Setup a cron-/batch-job that:
- (Optionally) Updates the rc-bugs files
- (Optionally) Updates the $STATE_DIR/age-policy-urgencies
- Runs Britney
- Imports the result into your target suite
Migration items
Britney generally works with a "migration item", which is a group of binary packages (and possibly a source package). Packages are bundled into these migration items under the following rules:
- "source migration": An update of the source package. This will include all the binary packages built from that source version (regardless of architecture).
- Can contain binaries built from earlier source version depending on the setting of "IGNORE_CRUFT"
- Britney refers to these as "${SOURCE_NAME}"
- "binary migration": An update of binary packages on a given architecture to an existing source package in the target suite.
- Two common cases: Built for the first time on a new architecture and binNMUs
- Britney refers to all cases of these as "${SOURCE_NAME}/${ARCHITECTURE}"
- "removal item": A removal of a source or binary package.
- Note that it is only possible to trigger "source" removals via hints. Binary removals are items generated by Britney to clean up the target suite.
- Britney refers to these as "-${SOURCE_NAME}" or "-${BINARY_NAME}/${ARCHITECTURE}" depending on the case.
Migration rules (excuses/policies)
Britney applies a number of policies to migration items before attempting to migrate them to the target suite. These policies can "reject" a package and prevent it from migrating. Some policies/built-in rules:
- Age policy: Lets source migrations age a bit before they are allowed to migrate
- Supports variable length based on package urgency
- RC Bug policy: Rejects packages with regressions in RC bugs
- Requires an external tool to keep the bug lists up to date
- Keeps architectures in sync: Source migrations updating existing packages only occur if architectures are up to date
- Can be configured to ignore certain architectures.