On Tue, 2008-03-11 at 12:19 -0800, Jeff Spaleta wrote: > On Tue, Mar 11, 2008 at 11:58 AM, Jeremy Katz <katzj@xxxxxxxxxx> 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 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
