On Mon, 22 Jun 2009 14:18:39 -0400, Tom wrote: > Jeff Spaleta writes: > > On Mon, Jun 22, 2009 at 8:32 AM, Dave Jones wrote: > >> Considering these updates are supposed to be for our 'stable' release, > >> having them be in $nextrelease first seems like a good idea anyway. > > > including rawhide? Yes, with exceptions and creating a warning at least. See below. > > Do you want security fix updates to block on rawhide not composing in > > order to prevent an upgrade path breakage. Not really, although the same question applies also to the other dists. Theoretically it would be possible that temporary build problems with a newer dist could cause a security fix for an older dist to be blocked. (e.g. foo-2.1-1.fc10 being ready to be pushed, but fc11 being stuck at foo-2.0-1.fc11 because foo-2.1-1.fc11 fails to build due to arbitrary issues one can imagine) > You could work around that by using a suitable definition of "pushed". > (You'd need a careful definition anyway, to not fail on an update > request that's trying to push to all the back branches at once.) > > However, there's still an issue if rawhide is so badly broken that a > package won't even *build* there, as we know happens occasionally. *Then* any such package that doesn't build in rawhide and would block updates for older dists shall be put onto a special MUST-FIX list that blocks Rawhide instead, so Rawhide cannot become the next Fedora release before these missing packages have been built successfully. With regard to security issues, you either run Rawhide already and then you may be vulnerable as long as the fix can't be built. Or you use an older dist release and you can get the fix for that dist, but in case of dependency problems and violated upgrade path to Rawhide, you can't upgrade to Rawhide. Tons better than upgrade issues between stable Fedora releases. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
