No subject

* Automatic weekly scratch builds for rawhide and for the F19 branch once it
  occurs. These should automatically use the latest kickstart from the
  cloud-kickstarts git repository, and the resulting qcow2 tar.xz'd raw and
  will go onto alt.fedoraproject.org. Ideally, this will all be scripted
  rather than manual. (Right now, one kickstart script per arch; in the
  future, we may want to have test versions of multiple different
  kickstarts, so the script should be a little flexible.)

  At FUDCon, Dennis mentioned that he was planning to do this for the
  install image, and this is only incrementally more than that, sot his
  should be covered.

* Continue what we're doing with EC2. If we can get the Marketplace legal
  issues settled, we'll only need to upload to US East and they'll do the
  rest, which will decrease work, but otherwise, it's the same as we've been
  doing, except a bit more formality with the alpha and beta builds.

* And then the qcow2 and raw.tar.xz builds for Alpha, Beta, and Final. These
  should go onto the mirror network along with the install ISOs and etc., and
  should have GPG-signed checksums. This probably needs at least some manual
  intervention, but isn't completely unlike the existing EC2 image process.

Is there anything I've missed, here? Are there parts of this which will
require significant effort which I'm overlooking? What parts can *I* take on
directly?

As we're developing the updates to Koji to integrate a new image build
process, are there functional needs from the release engineering point of
view that need to be specified? I know Dennis *really* doesn't like the idea
of running ImageFactory and Oz at the builder level, but based on the
conversations with Ian McLeod and Jay Greguske, these tools are actually
_meant_ to work that way, and I think we can satisfy the functional needs --
but it'd be helpful to have the functional needs spelled out.

Thanks!

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>