Spin Updates Policy Draft

Jeremy Katz 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.

Jeremy




More information about the fedora-advisory-board mailing list