On Friday, January 02, 2015 02:18:24 PM Rich Freeman wrote: > On Fri, Jan 2, 2015 at 1:10 PM, Ian Stakenvicius <a...@gentoo.org> wrote: > > The thing about stable gentoo-sources is that it shows that it's been > > tested, and ideally that testing's been done against the rdeps of the > > kernel package too (ie, external modules). ... > > That said, given the frequency of security updates, I do think it > > makes sense to try and keep the stabilization of LTS kernel versions > > in sync with upstream as much as possible, including > > quick-stabilization whenever we can. > > ++ and ++ > > Would an approach like this make sense: > 1. For ~arch keep doing what we're doing (which seems to be generally > following the upstream stable branches). > 2a. For stable always target the latest longterm, and commit straight > to stable. > or > 2b. For stable just follow ~arch a few days behind. > 3. Either way immediately remove packages that aren't > upstream-supported (by all means keep all the longterm/stable > branches, but don't leave cruft hanging around or abandoned stable > branches - if somebody ~arch tagged a particular branch and didn't get > the news that it won't go longterm then they'll either downgrade to a > supported stable or notice and adjust their keywords to go to the next > stable). > > 2a is extremely unlikely to break anything, but probably won't get any > testing so you might as well commit straight to stable (nobody running > ~arch is going to be running longterm as well). 2b is more likely to > break stuff, but on the other hand will be more likely to have actual > bugs reported so it will be more tested. > > The biggest issue I see is with packages that actually use recent > kernel features (systemd comes to mind, maybe udev to a lesser degree, > and I'm sure there are others). These kinds of packages should have > clear kernel dependencies though. In some sense EVERYTHING is an rdep > of the kernel so breakage could conceivably happen anywhere - but the > risk is higher in some places. > > I think the classical stable user is probably best off following > upstream longterm anyway, unless they just bought a new laptop or > something like that. > > In general though I think that it is perfectly acceptable to have a QA > policy specific to the kernel since upstream has very robust stable > branch support, and the level of QA and release maturity is extremely > high. > > I do think that it makes sense to not throw stable Gentoo users at > kernels that were mainline release candidates only a day before.
I understand your point. Maybe waiting a few days to auto stable makes sense, because less than 7 days later, a new version with bug/security fixes is released. Isn't our current rate of stabilization "selling" a promise of stability we can't stand behind? Mike -- Mike Pagano Gentoo Developer - Kernel Project Team Lead - Gentoo Sources E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
