| 1 |
On Fri, 21 Jun 2013 17:13:03 -0700 |
| 2 |
Greg KH <gregkh@g.o> wrote: |
| 3 |
|
| 4 |
> Great! But as only the latest version released is "stable", that's |
| 5 |
> all that should stick around, right? |
| 6 |
|
| 7 |
Tricky decision to make. Do we really want to force people's kernel |
| 8 |
sources to unmerge every single time you push a new version? Which on |
| 9 |
its own turn, forces them to build and install the new kernel. |
| 10 |
|
| 11 |
> > If possible we could script it to keep the package unstable the |
| 12 |
> > first X days it is in Portage to keep the stabilization effect in |
| 13 |
> > place; that way Gentoo users are unaffected if something goes wrong |
| 14 |
> > the day after you push a patch, I assume not, but you never know. |
| 15 |
> |
| 16 |
> If something goes "wrong" the day after I push a update, I push a new |
| 17 |
> one fixing the problem, so this shouldn't be an issue, right? |
| 18 |
|
| 19 |
It's not so much about fixing the problem, but rather about the |
| 20 |
severity of the issue. If this involves a corruption that corrupts a |
| 21 |
large amount of data on well known hardware which the patches were not |
| 22 |
tested on, users with such hardware would be affected; if we however |
| 23 |
delay our Gentoo users, they wouldn't become affected due to an |
| 24 |
upstream problem, unless they intentionally use the ~ keyword |
| 25 |
|
| 26 |
> And as these are coming out about 1-2 a week, the timeout before the |
| 27 |
> arch teams could get around to marking things stable seems like a lot |
| 28 |
> of work, for something that isn't really needed at all. |
| 29 |
|
| 30 |
What I meant was to not involve arch teams at all, as per the original |
| 31 |
proposal but just have a cron job running somewhere to stabilize the |
| 32 |
new versions, as well as to drop older versions. |
| 33 |
|
| 34 |
The delayed stabilization and delayed dropping from the tree are merely |
| 35 |
ideas that I think are in favor of the users; I may be wrong about this |
| 36 |
but would like to at least see this discussed, unless everyone agrees |
| 37 |
we should completely reflect the current state as listed on kernel.org. |
| 38 |
|
| 39 |
As you probably know, there are different groups of users where some |
| 40 |
run personal laptops or desktops whereas other run a (professional) |
| 41 |
server. I think an approach that what would make sense for people |
| 42 |
running a secure and stable server might not necessarily make sense for |
| 43 |
people running their own laptop or desktop. Not all exploits target |
| 44 |
both servers and desktops (eg. they can't get behind router). |
| 45 |
|
| 46 |
On the other hand, the vanilla-sources ebuilds set |
| 47 |
K_SECURITY_UNSUPPORTED="1"; so perhaps we're not even aiming for the |
| 48 |
(professional) server people at all and therefore perhaps only the |
| 49 |
laptop and desktop users. Or at least, that's how Gentoo Security and |
| 50 |
that variable would make it look like; I agree though that it is |
| 51 |
inconsistent with how upstream would look at these versions, I |
| 52 |
therofore think it should be a good idea to reevaluate said variable if |
| 53 |
we are going to change the way we stabilize and drop vanilla-sources. |
| 54 |
|
| 55 |
-- |
| 56 |
With kind regards, |
| 57 |
|
| 58 |
Tom Wijsman (TomWij) |
| 59 |
Gentoo Developer |
| 60 |
|
| 61 |
E-mail address : TomWij@g.o |
| 62 |
GPG Public Key : 6D34E57D |
| 63 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives