Improving the speed at which SRUs are reviewed and released

Registered by Brian Murray

The goal is to identify ways in which we can improve the throughput of the SRU process be it reviewing packages to go into -proposed or releasing packages to -updates.

Blueprint information

Not started
Steve Langasek
Needs approval
Brian Murray
Series goal:
Accepted for raring
Milestone target:

Related branches



= General =
* document daily tasks for SRU team members - may help others interested in joining know what the work is
= Incoming (the proposed queue) =
* Not easy to know what the person before you reviewed - need a way to hand off between reviewers
 * ScottK had mentioned rejecting packages from -proposed if they are missing data in the bug
 * yes these will be rejected straight away and the uploader should ping the SRU team when the bug is ready
 * extend sru-accept so that it will help with the rejection process / who to talk to
* Should there be a process for getting a package in -proposed prioritized?
 * document that ping-ing the SRU reviewer of the day
* A lot of fiddling about (and making of mistakes) could be avoided with three simple improvements to sru-accept:
  - Don't require version and bug arguments, but instead grab them from the .changes in the queue, which implies:
  - Hard fail if there's more than one copy/version in the queue, this is something that needs human intervention to sort out
  - Make sru-accept actually accept the upload
  - Rename it sru-process and should include:
   - the ability to open all the bugs (by default)
   - option to reject and send mail to uploader
   - grab the diff and display it
   - it will also be helpful if it were to say "these srus appear to be ready to released" and helped with the release process
= Outgoing (pending-sru report) =
* The time for removal is currently documented at half a year this should be decreased.
 * 90+15 days = 105 days
* Perhaps auto commenting on bugs needing verification at some interval would help
* There was talk of a patch pilot program for performing SRU verification - what happened?
* Was it well publicized / documented that uploaders could verify their own fix?
 * yes it was - it appeared in an e-mail from slangasek (no not really)
* There should be a way to watch for the package version that is in -proposed and any new crashes.
* Revisit the discussion regarding any package bugs having a regression-proposed tag making the verification-failed (or having the pending-sru report reflect that there is a package bug tagged regression-proposed)
Q: What about updating the description of bugs that are upstream bugs that
have had an Ubuntu task added?
Phased Updates can speed things up:
 - If we have a way to see errors about -proposed packages in we can verify a fix by the lack of new crash reports for that version
   - This is true, but it's not quite easy to find the error bucket for a given launchpad bug report, unfortunately
   - However sometimes the inverse happens: a bug gets escalated from errors.
     Either way if the error bucket gets to the bug report we are good.
   - the waiting period might need to be extended for SRUs that are fixing errors
How do we know people are actually installing the -proposed package?
 - "no new errors in error reporter" could just be a function of having no installs
 - but if we have > 1k crashes reported with the old version, and 0 with the new version, that's a good indicator
 - would be nice if we collected a bit of data from people who opt in to proposed about what packages they have installed.
Crash reporter:
 if you have proposed enabled then the "install update that might fix this crash" dialog could present the option to install the -proposed package and notify us that it's actually being installed.

Sponsors should not upload an SRU that don't have test cases, bug paperwork, etc... (paperwork comes first on bug; although don't need permission to upload to -proposed)


Work Items

Work items:
[brian-murray] Design tool to help process SRUs (review and accept or reject): INPROGRESS
[brian-murray] auto comment on bugs needing verification (indicate that it needs to happen in the next 15 days) at some interval (3 months): DONE
include stable release notes from archiveadmin page in SRU page: DONE
update SRU team documentation to mention that the security team should be pinged for any copies to the -security pocket: DONE
[brian-murray] review issues with quantity of bugs being tagged regression-update: DONE
[brian-murray] create a tool or modify a tool that will look for bugs about the same package that are from -proposed and that are tagged regression-proposed and then comment on / tag the SRU bug: DONE
[brian-murray] document pinging the SRU team member of the day in #ubuntu-release to escalate SRUs: DONE
[brian-murray] create a way to query for new crashes regarding a package version that is in -proposed: DONE
[brian-murray] update SRU documentation to indicate unverified packages in -proposed will be removed after 105 days: DONE