Spin Updates Policy Draft

Jeff Spaleta jspaleta at gmail.com
Tue Mar 11 20:19:18 UTC 2008


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.  And yes, we still need to address Jesse's concerns
about verifying that an externally built and hosted iso is not evil so
we can point to it. But however we address that, that process can be
applied to an updated spin that is meant to be contributed and not
hosted by Fedora.

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

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.

-jef




More information about the fedora-advisory-board mailing list