the mechanics of pushing updates

[Bill Nottingham]

Mmm, plumbing. bodhi is heading for production soon. To push updates, what
bodhi currently does is, for any update:

- sign the package
- copy the package to a 'staging' tree of the entirety of updates
- read a static list of packages that should be multilib, act on that
- run createrepo
- check deps on the repo
- rsync the whole repo out

Older updates are cleaned by a cron script later.

Advantages of this approach:
- it's simple
- it's easy to clean upthings that Go Wrong (just manually remove them
  from the repo and re-sync)

Disadvantages:
- multilib. In a world where we continually add new packages, this
  *will not scale*.

So, we need at least *some* sort of better workflow.

One alternative - using mash (what we're using to build rawhide.) It
would go something like this:

- sign the package
- tag the package (for updates-testing, or updates)
- run mash to create a repo of updates/updates-testing, solve it for
  multilib
- rsync it out

Advantages:
- solves multilib
- doesn't require continually keeping a staging tree around
- depcheck is built in when solving multilib
- builds on koji tags to let anyone easily query what updates are
  released

Disadvantages:
- by rebuilding the repo each time, it's going to be slow once
  the repo gets large
- harder to clear out other strangeness
- will only have one version of each updated package

The last of these isn't as *big* of a concern now, as all builds
will be available through the koji web site, space permitting.

Other ideas for better workflow? What do the extras push scripts do?
Do we want to add a modified version of mash's multilib solver into
bodhi?

(This is ignoring the process of rsyncing to the mirror master, which
will be gross.)

Bill