[fedora-virt] Improving release / update process for virt packages

[Mark McLoughlin]

On Mon, 2009-04-06 at 15:41 +0100, Daniel P. Berrange wrote:

> We currently have people doing various adhoc personal repos from scratch
> builds, so my suggestion is that formalize this under the umbrella of the
> Fedora Virtualization SIG. Specifically, to provide a 'virt-preview' YUM
> repo for the most recent stable stream (ie F10, but not F9).
> 
> In the designated virtualization package set, anytime we do a build of a
> new release for rawhide, we would also do a build for the 'preview' stream.
> We would explicitly not do these builds for the 'updates' repos, at least
> not without a very significant period of testing & positive feedback.
> 
> To allow us to do builds in both the preview stream, and updates stream,
> which are not scratch builds, this would unfortunately require another 
> CVS branch.

Just thinking about this some more. For now, I'm inclined to go for an
extremely low tech solution which requires no rel-eng support in order
to prove the concept.

Simply:

  1) When you do a build in rawhide, also do:

       make scratch-build TARGET=dist-f11

  2) Note the task number and on fedorapeople.org pull the packages 
     from:

       http://koji.fedoraproject.org/scratch/$(user)/task_$(task)/

     to e.g. ~/public_html/virt-f11-preview

     (We could add a Makefile to automate these two steps)

  3) I'll create a dir which just links to the various known preview 
     repos in peoples homedirs

  4) I'll regularly run createrepo in that dir

Yes, there are disadvantages in using scratch builds - e.g. no new
buildroot, so we can't build against other preview builds. But I'd
prefer to get this kicked off in some form rather and show that it's
useful, before getting into asking rel-eng for a new koji
target/buildroot etc.

>  We'd also need an NEVR that satisfies
> 
>  - Newer than current stable stream NEVR

This should happen fairly naturally - just don't do a preview build if
you're also going to build it for F-11.

>  - Older than the new build in rawhide

Satisfied by the dist tag.

>  - Allows for newer build to be later made in 'updates' repo

I'm not really concerned - if e.g. we were doing scratch builds of
libvirt-0.6.3 up to libvirt-0.6.3-10.fc11 and wanted to push to updates,
we could either decide:

  a) Just re-build libvirt-0.6.3-10.fc11 in updates; ignore the fact 
     that some folks have a different build of the same n-v-r

  b) Re-build as libvirt-0.6.3-11.fc12 in rawhide and push 
     libvirt-0.6.3-11.fc11 to updates

It sucks a little, but given the simplicity of just doing scratch
builds, I think we can live with it for now.

Cheers,
Mark.