Re: [fedora-virt] Improving release / update process for virt packages
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.