Spin Updates Policy Draft
katzj at redhat.com
Tue Mar 11 20:32:01 UTC 2008
On Tue, 2008-03-11 at 12:19 -0800, Jeff Spaleta wrote:
> On Tue, Mar 11, 2008 at 11:58 AM, Jeremy Katz <katzj at redhat.com> wrote:
> > Doesn't this also imply rel-eng taking on building said updates? Since
> > the hosted spins were also being built by rel-eng AFAIK at this point.
> If the updates are Release Update Spins, yes they are to be built like
> Release Spins because they are going to be hosted. If they are to be
> contributed update spins, then they don't require hosting from Fedora
> and they can be built and hosted like any contributed spin in the
> Kickstart Pool.
So that means we need buy-in from rel-eng to do more building of images.
I know that I personally don't have any spare cycles for doing so
> > Also, what's the plan around testing of updated spins? As there's more
> > stringent testing around spins that are going to be in the "release"
> > than what we do for the more informal Kickstart Spin Pool
> The devil's in the details. I was trying to trigger exactly this sort
> of additional testing from releng if there was a significant technical
> change in the kickstart file or if the package payload changed. I'm
> having a hard time envisoning a releng concern that would not be
> caught by the peer review process that allows it to swim in the pool.
The package payload _does_ change, though, as a result of updates. A
new kernel version could end up needing changes to the way the initrd
stuff works (has happened now more than once) as well as a multitude of
other things which creep into updates.
> I look at the peer review process as "this is broken or not" review. I
> look at the technical assessment in the Release Selection process
> which releng undertakes leading up to a release as "this works the
> right way or not" process. If the updated spin isn't changing the
> kickstart logic, and there are no significant deviations in the
> package manifest... are there going to be package update problems that
> won't be caught in a peer review? I guess it sort of depends on
> knowing what releng plans to do in terms of more extensive testing
> beyond which the peer review group can be tasked to do.
The actual release of a *release spin* involves the full brunt of
release testing. Some of the release criteria cover it (not entirely)
and so we do a fair bit of testing to ensure that things like installing
still works including some of the variety around that.
The other thing that is almost guaranteed to be a problem in an "update"
is getting things to fit. If it's a CD sized live image, then it's a
constant struggle to fit.
More information about the fedora-advisory-board