| 1 |
On Fri, Jan 2, 2015 at 1:10 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> |
| 3 |
> The thing about stable gentoo-sources is that it shows that it's been |
| 4 |
> tested, and ideally that testing's been done against the rdeps of the |
| 5 |
> kernel package too (ie, external modules). ... |
| 6 |
> That said, given the frequency of security updates, I do think it |
| 7 |
> makes sense to try and keep the stabilization of LTS kernel versions |
| 8 |
> in sync with upstream as much as possible, including |
| 9 |
> quick-stabilization whenever we can. |
| 10 |
|
| 11 |
|
| 12 |
++ and ++ |
| 13 |
|
| 14 |
Would an approach like this make sense: |
| 15 |
1. For ~arch keep doing what we're doing (which seems to be generally |
| 16 |
following the upstream stable branches). |
| 17 |
2a. For stable always target the latest longterm, and commit straight |
| 18 |
to stable. |
| 19 |
or |
| 20 |
2b. For stable just follow ~arch a few days behind. |
| 21 |
3. Either way immediately remove packages that aren't |
| 22 |
upstream-supported (by all means keep all the longterm/stable |
| 23 |
branches, but don't leave cruft hanging around or abandoned stable |
| 24 |
branches - if somebody ~arch tagged a particular branch and didn't get |
| 25 |
the news that it won't go longterm then they'll either downgrade to a |
| 26 |
supported stable or notice and adjust their keywords to go to the next |
| 27 |
stable). |
| 28 |
|
| 29 |
2a is extremely unlikely to break anything, but probably won't get any |
| 30 |
testing so you might as well commit straight to stable (nobody running |
| 31 |
~arch is going to be running longterm as well). 2b is more likely to |
| 32 |
break stuff, but on the other hand will be more likely to have actual |
| 33 |
bugs reported so it will be more tested. |
| 34 |
|
| 35 |
The biggest issue I see is with packages that actually use recent |
| 36 |
kernel features (systemd comes to mind, maybe udev to a lesser degree, |
| 37 |
and I'm sure there are others). These kinds of packages should have |
| 38 |
clear kernel dependencies though. In some sense EVERYTHING is an rdep |
| 39 |
of the kernel so breakage could conceivably happen anywhere - but the |
| 40 |
risk is higher in some places. |
| 41 |
|
| 42 |
I think the classical stable user is probably best off following |
| 43 |
upstream longterm anyway, unless they just bought a new laptop or |
| 44 |
something like that. |
| 45 |
|
| 46 |
In general though I think that it is perfectly acceptable to have a QA |
| 47 |
policy specific to the kernel since upstream has very robust stable |
| 48 |
branch support, and the level of QA and release maturity is extremely |
| 49 |
high. |
| 50 |
|
| 51 |
I do think that it makes sense to not throw stable Gentoo users at |
| 52 |
kernels that were mainline release candidates only a day before. |
| 53 |
|
| 54 |
-- |
| 55 |
Rich |
Archives