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