#5886: need method for distributing urgent fixes... urgently

[Fedora Release Engineering]

#5886: need method for distributing urgent fixes... urgently
------------------------------+-----------------------
  Reporter:  mattdm           |      Owner:  rel-eng@…
      Type:  enhancement      |     Status:  new
 Milestone:  Fedora 21 Alpha  |  Component:  mash
Resolution:                   |   Keywords:  meeting
Blocked By:                   |   Blocking:
------------------------------+-----------------------

Comment (by kevin):

 ok. I think what we need is a straw-man proposal for people to tweak/poke
 holes in, and so I will do so:

 prereqs:

 * bodhi adds fedora-urgent-NN setups. It's mash config has no drpms.
 Possibly it's interface doesn't even show this product if there are 0
 updates in it (which should be the normal state).

 * fedora-release-repos pushes out a version with a new fedora-urgent-
 updates and fedora-urgent-updates-testing repos. They use metalinks and
 normally point to a empty repo.

 Process:

 * Maintainer(s) follow the normal update process. Build in koji, submit
 update to bodhi, etc.

 * They submit a releng ticket asking for the update to be in urgent
 updates.

 * If approved, releng submits the update(s) to the urgent-updates product,
 signs them and pushes them to testing.

 * The repo is synced to a urgent-updates-testing repo and must get +3
 karma to pass this point.

 * On stable karma the update(s) are pushed to the urgent-updates repo and
 synced out.

 * Mirrormanager is poked to update the repodata and metalink, which at
 first just points to master mirrors, but over time as more sync adds more
 mirrors.

 * After the update goes to stable in normal updates + 1 week, the urgent
 updates repo is cleared out and empty repo is pushed out.

 comments:

 * This will be faster that current setup because it can be done
 independenty of normal updates pushes, the repos will be very small
 (mashing should take very little time), there are no drpms, etc.

 * The longest times here will be mirrormanager noticing the updated repos,
 and the human steps like noticing the ticket, pushing the updates, testing
 the updates, etc.

 * We really do need mirrormanager here unless we want all users to always
 hit master mirrors empty repo (which some may see as a way to track or
 count them). Also, we really want a metalink as it's much better than a
 baseurl.

 * We need bodhi here to have sanity checks like all rpms signed, repodata
 has security update info for security plugins, etc.

 Issues:

 * Is a releng ticket right to ask for this? Who approves it and how?

 * Is this going to be fast enough to make it worth while?

 * Is there a way to reduce waiting for humans here without bypassing some
 important checking?

-- 
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5886#comment:25>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project