Updates to testing migration schedules
-----BEGIN PGP SIGNED MESSAGE-----
A small infrastructure update from the release team. We have updated
the schedules of two tools related to testing migrations:
* Britney will now do migration from unstable to testing 4 times a day
with 6 hour intervals (matching the number of "dinstalls").
- The ageing (still) occurs for the 22:00 UTC run as it did
previously, which means the bulk of all migrations will still
occur at that point.
- Auto-removal hints are added once every day, just before the
10:00 UTC run
- The other runs can cause changes in testing due to changes in the
last 6 hours:
- Changes to RC bugs
- hints by the release team
- build for certain architectures being uploaded (or binNMUs)
- binary removals from unstable
* Britney now updates the "excuses" hourly. These excuses show if
packages will be candidates for migration to testing in the next
Britney run. Please note that many consumers (e.g.
tracker.debian.org/packages.qa.debian.org) only poll
release.debian.org at a much lower frequency (~4 times a day).
- For now, please use "grep-excuses" from devscripts to see the
* Effective on the 2017-04-18, we will shift the time of the migration
emails by 12 hours.
- This means you will see the emails appearing at about 04:39 UTC
rather than 16:39 UTC starting on the 18th of April.
- The timing is to align the mails with the changes done by the
22:00 UTC Britney run (of the preceding day) being committed.
Short about the rationale for these changes:
We hope that the hourly excuse updates means that it will be easier
for contributors to accurately and quickly assess the migration status
of their packages. There is no reason why you should have to wait 12
hours to learn that Britney was notified of a regression or that the
release team has applied a policy exception hint.
Many contributors rely on the email notifications to determine when a
package as migrated. These contributors generally experience a 12
hour delay between the migration of their packages (have been
committed) and them actually receiving the notification. By moving
the emails to 04:39 UTC, this delay is shorten to the minimum possible
for the majority of all migrations.
We did consider running the mail migration script more than once per
calendar day. However, due to some implementation details in these
scripts, we are not quite confident that it would work out as we would
like it to.
For the Release Team,
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----