Improving the speed at which SRUs are reviewed and released

= 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 errors.ubuntu.com 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 errors.ubuntu.com 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:
[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 errors.ubuntu.com 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