[gentoo-dev] Vanilla sources stabilization policy change

[gentoo-dev] Vanilla sources stabilization policy change

[Mike Pagano]

tl;dr

Summary

Team members working alongside upstream (and downstream) developer Greg k-h 
have decided to no longer request stabilization of the vanilla sources kernel.  
Team members and arch teams (understandably) are unable to keep up with the 
1-2 weekly kernel releases, and therefore will now direct users to always run 
the latest vanilla sources, or to run gentoo-sources for a fully Gentoo 
supported kernel. We will continue to do our best effort to request and get 
stabililzed g-s versions.


Details

Some facts:

1. Upstream release rate is now a much higher 1-2 kernels a week.
2. Very frequently, these releases contain security fixes.
3. This rate of release puts arch teams in a difficult position, since
it is unsustainable to try to keep up to date with stabilization
4. By continuing the policy of providing a stable vanilla kernel version, 
Gentoo is giving a false sense of security to its users, since by the time the 
kernel does get stabilized, a newer version with more security fixes is almost 
always already released

Eventually, we will be updating our project pages to reflect these changes. As 
always with me, constructive dialog concerning this policy is welcome.

Original thread of discussion:
http://thread.gmane.org/gmane.linux.gentoo.kernel/697

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail     : mpagano@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

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

Mike Pagano wrote:
> Team members working alongside upstream (and downstream) developer Greg k-h 
> have decided to no longer request stabilization of the vanilla sources kernel.  
> Team members and arch teams (understandably) are unable to keep up with the 
> 1-2 weekly kernel releases, and therefore will now direct users to always run 
> the latest vanilla sources

Maybe it would make sense to automatically stabilize every v-s kernel
right away?


//Peter

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On 24/07/13 01:37 PM, Peter Stuge wrote:
> Mike Pagano wrote:
>> Team members working alongside upstream (and downstream) developer Greg k-h 
>> have decided to no longer request stabilization of the vanilla sources kernel.  
>> Team members and arch teams (understandably) are unable to keep up with the 
>> 1-2 weekly kernel releases, and therefore will now direct users to always run 
>> the latest vanilla sources
> 
> Maybe it would make sense to automatically stabilize every v-s kernel
> right away?
> 
> 
> //Peter
> 

As has been stated, this implies that Gentoo QA has tested the packages
and found them to be reasonably safe for use.

Although stable kernels *have* been tested by many people before use,
Gentoo QA has *not* (officially) tested them, at least not on every
architecture.

On a technical level, it's not that hard to put
"sys-kernel/vanilla-sources" in your package.accept_keywords.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Rich Freeman]

On Wed, Jul 24, 2013 at 1:43 PM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> As has been stated, this implies that Gentoo QA has tested the packages
> and found them to be reasonably safe for use.

++

Stable should mean something, and those who understand the tradeoffs
can accept unstable packages where needed (far more easily than on
most other distros I might add).

If gentoo-sources is where our stable efforts will be, then the
keywords should reflect this.  We're not getting rid of
vanilla-sources.

Rich

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

Rich Freeman wrote:
> > As has been stated, this implies that Gentoo QA has tested the packages
> > and found them to be reasonably safe for use.
> 
> ++

While good in theory, it seems that newer v-s are actually more
"reasonably safe" than any g-s.


> Stable should mean something

For users, stable means "older" in practice. Always did, always will.


> If gentoo-sources is where our stable efforts will be, then the
> keywords should reflect this.  We're not getting rid of
> vanilla-sources.

Ideally distribution efforts to stabilize packages should go
upstream instead of staying within the distribution.

Sadly not all upstreams are competent enough to handle that. :\


//Peter

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Rich Freeman]

On Wed, Jul 24, 2013 at 1:54 PM, Peter Stuge <peter@stuge.se> wrote:
> Rich Freeman wrote:
>
>> Stable should mean something
>
> For users, stable means "older" in practice. Always did, always will.

If you don't like stable, then don't run stable.  Don't change the
meaning of stable, however, for those who find it useful.

I've never had a problem with Gentoo stable.  If it doesn't work, it
should be dropped entirely on the arches that don't keep up (even if
that means all of them).  Defining stable to mean "no testing at all
except by the maintainer" just makes the keyword meaningless - ~arch
packages are supposed to be tested by the maintainer already.

The main distinction between stable and testing is fewer updates.  I'm
sure the average person who runs mythtv with versions synced across 3
systems doesn't need every monthly patch set I push out, but once in a
while I'll stabilize a keeper, and if somebody wants a particular
feature sooner they can do the extra work.  If a security update comes
out the stable users still get them.

If gentoo-sources isn't complying with our GLSA standards I think that
is worth bringing attention (and help) to, but I've yet to hear that
mentioned.

Rich

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

Rich Freeman wrote:
> >> Stable should mean something
> >
> > For users, stable means "older" in practice. Always did, always will.
> 
> Don't change the meaning of stable, however, for those who find it useful.

This is a good point, but the original post suggested to me that
actually every new release of v-s is preferable over every older
one and perhaps even over g-s because there are more fixes.


> Defining stable to mean "no testing at all except by the maintainer"
> just makes the keyword meaningless

I do think it's meaningless, though in a different way than you mean.

But back on track:

1. "stable" in Gentoo means "Gentoo QA-approved" and it is the default
2. v-s will never be stable
3. g-s will always be behind v-s, the latter having more fixes

It just seems to me that stable isn't a good default for the kernel
because of 2 and 3, and as a result users end up having fewer fixes,
since g-s is older.


> The main distinction between stable and testing is fewer updates.

If QA had infinite resources I suppose that wouldn't be the case.
I think it's important to stick to the actual definition of stable
meaning QA-approved.


> If gentoo-sources isn't complying with our GLSA standards I think
> that is worth bringing attention (and help) to, but I've yet to
> hear that mentioned.

Is that somehow implied by the original post, which states that g-s
can be expected to always lack the newest fixes in v-s?

I realize that this isn't such a simple matter, but I think it's
worth consideration.


To be clear: I am not suggesting to change the meaning of stable,
I am suggesting that the latest available upstream kernel should
perhaps be the default for Gentoo users. How to make that happen
is less important, the idea to automatically mark v-s stable is
only that, an idea. :)


//Peter

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Ben Kohler]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On Wed, Jul 24, 2013 at 2:01 PM, Peter Stuge <peter@stuge.se> wrote:
>
>
> To be clear: I am not suggesting to change the meaning of stable,
> I am suggesting that the latest available upstream kernel should
> perhaps be the default for Gentoo users. How to make that happen
> is less important, the idea to automatically mark v-s stable is
> only that, an idea. :)
>
>
> //Peter
>
> You seem to be ignoring the regressions that often come with new kernel
releases, the very common breakage caused in stable "genkernel all", and
other various complications.  Unleashing brand new kernel.org sources on
stable users as soon as they are released seems crazy to me.  These
releases surely bring more than just "the newest fixes".

Going straight to stable is (in my eyes) so far from being a viable option,
that "always unstable, allow unstable if you're ok with the risk/benefit
tradeoff" seems like the best bet, to me.

-Ben

[-- Attachment #2: Type: text/html, Size: 1495 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

Ben Kohler wrote:
> > I am suggesting that the latest available upstream kernel should
> > perhaps be the default for Gentoo users.
> 
> You seem to be ignoring the regressions that often come with new kernel
> releases, the very common breakage caused in stable "genkernel all", and
> other various complications.  Unleashing brand new kernel.org sources on
> stable users as soon as they are released seems crazy to me.

I don't know, I think it makes a lot of sense..

Users who upgrade their kernels (don't upgrade if you don't want to)
would be able to participate upstream with reports and confirmations.


> These releases surely bring more than just "the newest fixes".

It varies but sure, I think users should inform themselves about the
new version (of any package!) before they actually upgrade it.


//Peter

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

On Wed, 24 Jul 2013 21:15:15 +0200
Peter Stuge <peter@stuge.se> wrote:

> Ben Kohler wrote:
> > > I am suggesting that the latest available upstream kernel should
> > > perhaps be the default for Gentoo users.
> > 
> > You seem to be ignoring the regressions that often come with new
> > kernel releases, the very common breakage caused in stable
> > "genkernel all", and other various complications.  Unleashing brand
> > new kernel.org sources on stable users as soon as they are released
> > seems crazy to me.
> 
> I don't know, I think it makes a lot of sense..
> 
> Users who upgrade their kernels (don't upgrade if you don't want to)
> would be able to participate upstream with reports and confirmations.

It isn't a necessity to run the latest kernels to be supported, it
suffices to test them to see if they fix the situation or not. We look
at the fault ourselves, check newer kernels for fixes, bisect and
upstream stuff if it is out of our hand; For example with

https://bugs.gentoo.org/show_bug.cgi?id=458746#c26

we are contributing to upstream bug

https://bugzilla.kernel.org/show_bug.cgi?id=55311#c40

Of course users can do this outside of us; it's up to them, but they
should know we're always there to aid them in troubleshooting whereas
upstream might not always answer or follow through closely.

Just saying, there isn't anything that prohibits them; as long as their
version is listed on https://www.kernel.org/ they are fine.

> > These releases surely bring more than just "the newest fixes".
> 
> It varies but sure, I think users should inform themselves about the
> new version (of any package!) before they actually upgrade it.

Some people do, some people don't; it's though to do this for every
package and every release, it also requires some basic knowledge of the
kernel to understand what is really going in the kernel world.

I agree they should inform themselves; also, we should probably also
point them at the right resources, maybe http://kernelnewbies.org/
fits better than an incomprehensible git shortlog or changelog.

Will look at that in the near future; since some documentation
and project pages are moving to the Gentoo Wiki, it makes it more easy
and accessible to add useful resources for matters like these.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Rich Freeman]

On Wed, Jul 24, 2013 at 3:15 PM, Peter Stuge <peter@stuge.se> wrote:
> Ben Kohler wrote:
>> > I am suggesting that the latest available upstream kernel should
>> > perhaps be the default for Gentoo users.
>>
>> You seem to be ignoring the regressions that often come with new kernel
>> releases, the very common breakage caused in stable "genkernel all", and
>> other various complications.  Unleashing brand new kernel.org sources on
>> stable users as soon as they are released seems crazy to me.
>
> I don't know, I think it makes a lot of sense..
>
> Users who upgrade their kernels (don't upgrade if you don't want to)
> would be able to participate upstream with reports and confirmations.

How will users know which kernels they should upgrade to.  If the
latest is always the greatest then:
1.  Why wouldn't users always update 2x/week?
2.  Why doesn't every other distro do this?

The reality is that there are multiple kernel versions that are
getting updates at any time.  The latest and greatest is also the one
where all the new features are introduced, and likely all the
regressions.  Fixes are backported to older kernels which are still
supported.

Stable shouldn't track the latest kernel.  At best it should track the
latest version of an older kernel series.  It need not be an LTS one,
but it shouldn't be the current dev branch.

Also, not all fixes are equal.  The ones that are the biggest concern
are security fixes.  If you tell me that the kernel has a new exploit
2x/week then I'll start to wonder when the kernel team started
outsourcing to MS.  Most fixes provide no benefit to most users.
Upgrading kernels on Gentoo is not automatic either, especially if you
have an initramfs, complex configuration, modules in outside packages
(nvidia, virtualization, etc), and so on.

It just seems like we should be able to get by without a semiweekly
kernel upgrade on our "stable" branch.

Rich

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

On Wed, 24 Jul 2013 16:40:38 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> Also, not all fixes are equal.  The ones that are the biggest concern
> are security fixes.

Why? Which is worse: a local denial of service attack when every user
on your box has sudo access anyway, or a random data corruption bug
that can't be triggered manually and is thus not a security issue?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote:
> Also, not all fixes are equal.  The ones that are the biggest concern
> are security fixes.

How do you _know_ which fixes are security fixes?

> If you tell me that the kernel has a new exploit
> 2x/week then I'll start to wonder when the kernel team started
> outsourcing to MS.  Most fixes provide no benefit to most users.
> Upgrading kernels on Gentoo is not automatic either, especially if you
> have an initramfs, complex configuration, modules in outside packages
> (nvidia, virtualization, etc), and so on.

I'm releasing, on the average, 3 new kernel versions a week, with 100+
patches in them (for different branches.)  Sometimes more.  Please tell
me exactly how you are going to evaluate which fixes I make are security
fixes, and you know which to pick and choose from.

Trust me, it's a hard problem, people have tried it in the past, and
failed horribly :)

> It just seems like we should be able to get by without a semiweekly
> kernel upgrade on our "stable" branch.

You want me to slow down and do releases in larger chunks then?  Hah,
not a chance...

good luck,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Rich Freeman]

On Wed, Jul 24, 2013 at 7:09 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote:
>> It just seems like we should be able to get by without a semiweekly
>> kernel upgrade on our "stable" branch.
>
> You want me to slow down and do releases in larger chunks then?  Hah,
> not a chance...
>

To clarify - I wasn't criticizing your release schedule or making all
those builds available in ~arch.   I was only concerned with the idea
of making all those hit stable.  I think the kernel team (including
yourself) have been doing a great job with the stable kernels in
general.

Just one other note - stable packages in general don't just benefit
from arch testing.  They also benefit from users running ~arch and
reporting issues.  Stable ebuilds are ones that have generally been
used by many others for about a month already, so issues are likely to
have been caught.

I do agree with all that has been said about there being a tradeoff
between new regressions and new fixes.  Unless we run year-old kernels
with tons of backports we're going to have that problem.  We aren't
RHEL.

Rich

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

On Wed, 24 Jul 2013 16:09:11 -0700
Greg KH <gregkh@gentoo.org> wrote:

> Please
> tell me exactly how you are going to evaluate which fixes I make are
> security fixes, and you know which to pick and choose from.

Some kind of annotation with tags would make this kind of thing easy;
I'm not saying it is your task to apply such annotations to commits, but
it would rather be the task of the person who makes an individual patch.

This would benefit multiple people; it would benefit users to know the
amount of patches that are security and code fixes, new features and
see them separately. It would also benefit distributions and system
admins to filter them out, they could for instance drop new feature
patches so they just get the fixes they need.

It puts the power in the user's hands; allowing them to evaluate, pick
and choose according to their own demands and needs.

Implementation wise, I don't think this is any harder than the already
existing annotations; work wise, adding a tag is easy to do.

Maybe I should write up something more technical and throw it at the
upstream kernel ML for people to consider. Is there someone whom I need
to CC in specific if I do that?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
> On Wed, 24 Jul 2013 16:09:11 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > Please
> > tell me exactly how you are going to evaluate which fixes I make are
> > security fixes, and you know which to pick and choose from.
> 
> Some kind of annotation with tags would make this kind of thing easy;
> I'm not saying it is your task to apply such annotations to commits, but
> it would rather be the task of the person who makes an individual patch.

I am not going to impose an additional burden on developers to get their
patches into the stable kernel releases like this, sorry.

Can you judge which bug fixes are security ones, and which are not?  And
do so for 100+ patches a week?  52 weeks a year?  Great, please do so,
as no one has ever been able to do this (others have tried.)

Hint, the line between a bugfix and a security fix is not always
obvious, or even known at all.

And what about all of the fixes I merge in, that _are_ really security
fixes, yet we do not want to shout it out to the world at the moment?
How would one properly "tag" that?

> This would benefit multiple people; it would benefit users to know the
> amount of patches that are security and code fixes, new features and
> see them separately. It would also benefit distributions and system
> admins to filter them out, they could for instance drop new feature
> patches so they just get the fixes they need.
> 
> It puts the power in the user's hands; allowing them to evaluate, pick
> and choose according to their own demands and needs.
> 
> Implementation wise, I don't think this is any harder than the already
> existing annotations; work wise, adding a tag is easy to do.

See above for why it is not easy at all, and, why even if we do know
some fixes are security ones, we would not tag them as such anyway.

So that kind of makes that whole idea fall apart, right?  :)

sorry,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

Greg KH wrote:
> See above for why it is not easy at all, and, why even if we do know
> some fixes are security ones, we would not tag them as such anyway.

I think this supports the argument that the better kernel is always
the one with the most fixes.

Rather than separating "bug fixes" from "security fixes" maybe it's
wiser to think about separating "fixes" from "features" - this may
be easier, but still not neccessarily easy.


//Peter

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> Greg KH wrote:
> > See above for why it is not easy at all, and, why even if we do know
> > some fixes are security ones, we would not tag them as such anyway.
> 
> I think this supports the argument that the better kernel is always
> the one with the most fixes.

That's what us kernel developers have been saying for 10+ years, nice to
see it's finally getting some traction :)

> Rather than separating "bug fixes" from "security fixes" maybe it's
> wiser to think about separating "fixes" from "features" - this may
> be easier, but still not neccessarily easy.

For stable kernel releases, that type of thing should be quite easy for
someone to do, if they want to do it, as the only type of "features" I
take for them are new device ids.

But I fail to see how marking 5 patches out of 100 as "features" is
really doing to do much for anyone, do you?

thanks,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

On Wed, 7 Aug 2013 16:19:43 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> > Greg KH wrote:
> > > See above for why it is not easy at all, and, why even if we do
> > > know some fixes are security ones, we would not tag them as such
> > > anyway.
> > 
> > I think this supports the argument that the better kernel is always
> > the one with the most fixes.

Define "better"; because 3.10.0 has also been worse than the last 3.9
release in some ways, despite it having more fixes than the last 3.9.

> > Rather than separating "bug fixes" from "security fixes" maybe it's
> > wiser to think about separating "fixes" from "features" - this may
> > be easier, but still not neccessarily easy.
> 
> For stable kernel releases, that type of thing should be quite easy
> for someone to do, if they want to do it, as the only type of
> "features" I take for them are new device ids.
>
> But I fail to see how marking 5 patches out of 100 as "features" is
> really doing to do much for anyone, do you?

Preferably this would be done for any release, a release like 3.10.0
doesn't have to be an exception; it does contain a lot more features.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
> On Wed, 7 Aug 2013 16:19:43 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> > > Greg KH wrote:
> > > > See above for why it is not easy at all, and, why even if we do
> > > > know some fixes are security ones, we would not tag them as such
> > > > anyway.
> > > 
> > > I think this supports the argument that the better kernel is always
> > > the one with the most fixes.
> 
> Define "better"; because 3.10.0 has also been worse than the last 3.9
> release in some ways, despite it having more fixes than the last 3.9.

How was it "worse"?  You don't seem to define that either :)

Yes, there are always going to be bugs and regressions, but as long as
we are fixing them more than we are making them, we are doing ok.

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

On Thu, 8 Aug 2013 15:29:06 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
> > 
> > > On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
> > > > I think this supports the argument that the better kernel is
> > > > always the one with the most fixes.
> > 
> > Define "better"; because 3.10.0 has also been worse than the last
> > 3.9 release in some ways, despite it having more fixes than the
> > last 3.9.
> 
> How was it "worse"?  You don't seem to define that either :)

The point is rather whether it can be defined, therefore it is also
worse in some ways; of course without statistics you can't really
define it, but as long as there is reason to believe it people are
going to follow this train of thoughts. For example, the LTS kernels.

> Yes, there are always going to be bugs and regressions, but as long as
> we are fixing them more than we are making them, we are doing ok.

That's might be a false impression; have you took a set of commits from
back in time, analyzed what they caused and have a report available?

There's reason enough to be wary of refactoring, new features and more
to regress the first release of a new branch; and none of these are
actually fixes, they are not ok when you are looking for stability.

(Add to that that fixes can also cause bugs and regressions.)

Later releases in a branch don't contain such commits, only fixes; so,
therefore skipping the first releases of a branch is a normal thing to
do, unless there's proof or more convincing argumentation that it is a
stupid thing to do I don't see a change in this behavior any time soon.

Without statistics, neither person is wrong or right; so, both behaviors
happen and are based on thoughts, reasoning and beliefs. So, when stated
that the "better kernel is always the one with the most fixes" one needs
to objectively define "better"; otherwise that sentence is meaningless.

Without a definition and supporting evidence, that is a contradiction.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

Greg KH wrote:
> > > See above for why it is not easy at all, and, why even if we do know
> > > some fixes are security ones, we would not tag them as such anyway.
> > 
> > I think this supports the argument that the better kernel is always
> > the one with the most fixes.
> 
> That's what us kernel developers have been saying for 10+ years, nice to
> see it's finally getting some traction :)

It has been obvious for me for a very long time as well, but I am
just one person, and my idea doesn't seem to have much traction in
Gentoo. :\


> > Rather than separating "bug fixes" from "security fixes" maybe it's
> > wiser to think about separating "fixes" from "features" - this may
> > be easier, but still not neccessarily easy.
> 
> For stable kernel releases, that type of thing should be quite easy for
> someone to do, if they want to do it, as the only type of "features" I
> take for them are new device ids.
> 
> But I fail to see how marking 5 patches out of 100 as "features" is
> really doing to do much for anyone, do you?

For stable kernel releases there would be no need. I think they
should be stabilized automatically in Gentoo. It's simply a more
accurate model of upstream.


//Peter

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

On Fri, 9 Aug 2013 01:44:12 +0200
Peter Stuge <peter@stuge.se> wrote:

> > > I think this supports the argument that the better kernel is
> > > always the one with the most fixes.
> > 
> > That's what us kernel developers have been saying for 10+ years,
> > nice to see it's finally getting some traction :)
> 
> It has been obvious for me for a very long time as well, but I am
> just one person, and my idea doesn't seem to have much traction in
> Gentoo. :\

When you state a contradiction [1], there is nothing convincing about
it; the sentence as you made it there, can be interpreted in both ways.

 [1]: <20130809101023.6618a356@TOMWIJ-GENTOO>
      See the previous mail I just sent out.

> > > Rather than separating "bug fixes" from "security fixes" maybe
> > > it's wiser to think about separating "fixes" from "features" -
> > > this may be easier, but still not neccessarily easy.
> > 
> > For stable kernel releases, that type of thing should be quite easy
> > for someone to do, if they want to do it, as the only type of
> > "features" I take for them are new device ids.
> > 
> > But I fail to see how marking 5 patches out of 100 as "features" is
> > really doing to do much for anyone, do you?
> 
> For stable kernel releases there would be no need.

Depends on your own needs; but, identifying security fixes so they can
be applied in a timely fashion as well as back ported and what not
would definitely help. Why should the fact be hidden or slowly deduced
that a commit is a security fix. Collaboration would really help...

> I think they should be stabilized automatically in Gentoo. It's
> simply a more accurate model of upstream.

With 30 days delay, as well as bugs that block stabilization; there is
nowhere in Gentoo an accurate model of upstream, if it were then it
would be my mere luck. I don't see why the kernel should differ...

At most, we do our best to keep up where we can; if not, there's always
keywords like "~" and "" for people that want to be more bleeding edge.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

On Wed, 7 Aug 2013 15:44:34 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
>
> > Some kind of annotation with tags would make this kind of thing
> > easy; I'm not saying it is your task to apply such annotations to
> > commits, but it would rather be the task of the person who makes an
> > individual patch.
> 
> I am not going to impose an additional burden on developers to get
> their patches into the stable kernel releases like this, sorry.

As I said, it's not your task; so, what you impose doesn't matter.

> Can you judge which bug fixes are security ones, and which are not?
> And do so for 100+ patches a week?  52 weeks a year?  Great, please
> do so, as no one has ever been able to do this (others have tried.)

Yes, that is easy on the premise that they are annotated.

> Hint, the line between a bugfix and a security fix is not always
> obvious, or even known at all.

The developer knows; and if not, he can probably just mark it as a fix.

> And what about all of the fixes I merge in, that _are_ really security
> fixes, yet we do not want to shout it out to the world at the moment?

For known security bugs, being aware of a fix earlier helps.

> How would one properly "tag" that?

That's explained below, and would be explained in technical details.

> > This would benefit multiple people; it would benefit users to know
> > the amount of patches that are security and code fixes, new
> > features and see them separately. It would also benefit
> > distributions and system admins to filter them out, they could for
> > instance drop new feature patches so they just get the fixes they
> > need.
> > 
> > It puts the power in the user's hands; allowing them to evaluate,
> > pick and choose according to their own demands and needs.
> > 
> > Implementation wise, I don't think this is any harder than the
> > already existing annotations; work wise, adding a tag is easy to do.
> 
> See above for why it is not easy at all, and, why even if we do know
> some fixes are security ones, we would not tag them as such anyway.

Neither seems to be a problem.

> So that kind of makes that whole idea fall apart, right?  :)

The kernel ML will tell whether it does or not. :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
> On Wed, 7 Aug 2013 15:44:34 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
> >
> > > Some kind of annotation with tags would make this kind of thing
> > > easy; I'm not saying it is your task to apply such annotations to
> > > commits, but it would rather be the task of the person who makes an
> > > individual patch.
> > 
> > I am not going to impose an additional burden on developers to get
> > their patches into the stable kernel releases like this, sorry.
> 
> As I said, it's not your task; so, what you impose doesn't matter.

What do you mean by that?  I am the upstream stable kernel maintainer,
as well as a subsystem maintainer.  I don't want to do the extra work of
tagging all of my stable patches with this type of information, I can
barely keep on top of the ones that I have to mark for stable as it is.

As the stable kernel maintainer, all I ask for is that subsystem
maintainers tag their patches for the stable tree.  If I have questions
about them, I ask, otherwise I accept them.

> > Can you judge which bug fixes are security ones, and which are not?
> > And do so for 100+ patches a week?  52 weeks a year?  Great, please
> > do so, as no one has ever been able to do this (others have tried.)
> 
> Yes, that is easy on the premise that they are annotated.

But I will argue that you can not annotate them "properly".  That is
imposing more work on me, a subsystem maintainer, that I will not do.

> > Hint, the line between a bugfix and a security fix is not always
> > obvious, or even known at all.
> 
> The developer knows; and if not, he can probably just mark it as a fix.

Ok, so you have just now divided everything into "fix" or "feature".  As
the "feature" patches are quite obvious, everything else must be "fix".
So why tag anything, your classification is already done for you.

> > And what about all of the fixes I merge in, that _are_ really security
> > fixes, yet we do not want to shout it out to the world at the moment?
> 
> For known security bugs, being aware of a fix earlier helps.

I don't understand what you mean here at all.

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

On Thu, 8 Aug 2013 15:32:45 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
> > On Wed, 7 Aug 2013 15:44:34 -0700
> > Greg KH <gregkh@gentoo.org> wrote:
> > 
> > > I am not going to impose an additional burden on developers to get
> > > their patches into the stable kernel releases like this, sorry.
> > 
> > As I said, it's not your task; so, what you impose doesn't matter.
> 
> What do you mean by that?  I am the upstream stable kernel maintainer,
> as well as a subsystem maintainer.  I don't want to do the extra work
> of tagging all of my stable patches with this type of information, I
> can barely keep on top of the ones that I have to mark for stable as
> it is.
>
> > ...
>
> But I will argue that you can not annotate them "properly".  That is
> imposing more work on me, a subsystem maintainer, that I will not do.

Not just stable patches, but any patch; why delay till after the fact?

Tagging at the time of committing is just a few extra characters.

> > > Hint, the line between a bugfix and a security fix is not always
> > > obvious, or even known at all.
> > 
> > The developer knows; and if not, he can probably just mark it as a
> > fix.
> 
> Ok, so you have just now divided everything into "fix" or "feature".
> As the "feature" patches are quite obvious, everything else must be
> "fix". So why tag anything, your classification is already done for
> you.

If they are obvious, what's so hard abut tagging them?

No classification is done if there is no single command to obtain them.

> > > And what about all of the fixes I merge in, that _are_ really
> > > security fixes, yet we do not want to shout it out to the world
> > > at the moment?
> > 
> > For known security bugs, being aware of a fix earlier helps.
> 
> I don't understand what you mean here at all.

Neither do I understand what you mean by not shouting it out; so,
unless you have argumentation to not shout it out, I'm in the belief
that the faster one is able to apply a security fix, the more secure he
is as a result. If not shouting it out makes things more secure, then
please state me how and why; because it only gives attackers more time.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Rich Freeman]

On Fri, Aug 9, 2013 at 4:34 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Thu, 8 Aug 2013 15:32:45 -0700
> Greg KH <gregkh@gentoo.org> wrote:
>> On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
>> > > And what about all of the fixes I merge in, that _are_ really
>> > > security fixes, yet we do not want to shout it out to the world
>> > > at the moment?
>> >
>> > For known security bugs, being aware of a fix earlier helps.
>>
>> I don't understand what you mean here at all.
>
> Neither do I understand what you mean by not shouting it out; so,
> unless you have argumentation to not shout it out, I'm in the belief
> that the faster one is able to apply a security fix, the more secure he
> is as a result. If not shouting it out makes things more secure, then
> please state me how and why; because it only gives attackers more time.

I think that you guys are talking past each other to an extent.

My sense is that Greg is using the term security bugs to refer to
implementation errors that could be exploited to obtain unintended
access to a system.  Using this definition, any bug could be a
security bug, and figuring this out is about as easy as figuring out
whether a particular move is a good or bad one in chess.

I think Tom is using the term security bug to refer to a bug that has
a published exploit against it (ie a CVE/etc).  Using this definition
it is clear whether a particular bug is a security bug - it is either
in the database or it isn't.

I don't follow the kernel closely, but my guess is that they stay
well-ahead of CVE most of the time.  I'd certainly say that any
project should clearly document which releases incorporate fixes to
CVEs - perhaps the kernel already does this.  Since most bugs get
fixed before anybody bothers to file a CVE, I'm not sure how much that
actually matters in practice.

Frankly with the huge volume of changes and frequent releases I'm
amazed the kernel works as well as it does!  Greg gave a talk about
the rate of change and the implications for those submitting changes
recently - I'm sure it is on youtube/etc somewhere.

Rich

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

On Fri, 9 Aug 2013 06:38:56 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> My sense is that Greg is using the term security bugs to refer to
> implementation errors that could be exploited to obtain unintended
> access to a system.  Using this definition, any bug could be a
> security bug, and figuring this out is about as easy as figuring out
> whether a particular move is a good or bad one in chess.

That's indeed not what I understood; Greg, was this your though?

> I think Tom is using the term security bug to refer to a bug that has
> a published exploit against it (ie a CVE/etc).  Using this definition
> it is clear whether a particular bug is a security bug - it is either
> in the database or it isn't.

This is indeed what I assumed Greg meant; so, thanks for clarifying.

> I don't follow the kernel closely, but my guess is that they stay
> well-ahead of CVE most of the time.  I'd certainly say that any
> project should clearly document which releases incorporate fixes to
> CVEs - perhaps the kernel already does this.

Currently I don't see this; so, my assumption was that it does not
currently happen, as far as I have seen this appears to happen on an
individual basis, but I assume not everyone does report to CVE.

Reporting to CVE is much more work than it takes to tag a commit; so,
as you can see tagging here might be a benefit to lift the work to
other people that have more time for reporting it as a CVE, etc...

> Since most bugs get fixed before anybody bothers to file a CVE, I'm
> not sure how much that actually matters in practice.

It is dangerous to assume something you fix isn't known yet. As I said
before, it buys the people that do know time; whether or not a CVE or
any other form of public or less public documentation on it exists.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Fri, Aug 09, 2013 at 03:28:54PM +0200, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 06:38:56 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
> > My sense is that Greg is using the term security bugs to refer to
> > implementation errors that could be exploited to obtain unintended
> > access to a system.  Using this definition, any bug could be a
> > security bug, and figuring this out is about as easy as figuring out
> > whether a particular move is a good or bad one in chess.
> 
> That's indeed not what I understood; Greg, was this your though?

Yes, that's close to the issue.  Any bug could be classified as a
"security" bug if you wish to do so, so there's no need to call out some
fixes and not others, as odds are, you will miss some, and give people
the wrong impression they are safe when they are really not.

> > I don't follow the kernel closely, but my guess is that they stay
> > well-ahead of CVE most of the time.  I'd certainly say that any
> > project should clearly document which releases incorporate fixes to
> > CVEs - perhaps the kernel already does this.
> 
> Currently I don't see this; so, my assumption was that it does not
> currently happen, as far as I have seen this appears to happen on an
> individual basis, but I assume not everyone does report to CVE.
> 
> Reporting to CVE is much more work than it takes to tag a commit; so,
> as you can see tagging here might be a benefit to lift the work to
> other people that have more time for reporting it as a CVE, etc...

The kernel usually has things fixed it in long before a CVE is asked
for.  So there's no way to go back in time and add CVEs to commits.

thanks,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Fri, Aug 09, 2013 at 10:34:58AM +0200, Tom Wijsman wrote:
> On Thu, 8 Aug 2013 15:32:45 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
> > > On Wed, 7 Aug 2013 15:44:34 -0700
> > > Greg KH <gregkh@gentoo.org> wrote:
> > > 
> > > > I am not going to impose an additional burden on developers to get
> > > > their patches into the stable kernel releases like this, sorry.
> > > 
> > > As I said, it's not your task; so, what you impose doesn't matter.
> > 
> > What do you mean by that?  I am the upstream stable kernel maintainer,
> > as well as a subsystem maintainer.  I don't want to do the extra work
> > of tagging all of my stable patches with this type of information, I
> > can barely keep on top of the ones that I have to mark for stable as
> > it is.
> >
> > > ...
> >
> > But I will argue that you can not annotate them "properly".  That is
> > imposing more work on me, a subsystem maintainer, that I will not do.
> 
> Not just stable patches, but any patch; why delay till after the fact?
> 
> Tagging at the time of committing is just a few extra characters.

And don't people do that already with their changelog comments in the
kernel?

No, not in any "offical" format, but that's been rejected numerous
times.  Just read the commits to find out what is resolved, if anything
is known at that point in time, if you are curious.


> > > > Hint, the line between a bugfix and a security fix is not always
> > > > obvious, or even known at all.
> > > 
> > > The developer knows; and if not, he can probably just mark it as a
> > > fix.
> > 
> > Ok, so you have just now divided everything into "fix" or "feature".
> > As the "feature" patches are quite obvious, everything else must be
> > "fix". So why tag anything, your classification is already done for
> > you.
> 
> If they are obvious, what's so hard abut tagging them?

Because it's extra work that is pointless.  You do realize just how many
patches go into the kernel every day, right?  Doing anything to a patch
will slow things down, and given the huge number of the, odds are a
percentage will be wrong anyway.

> No classification is done if there is no single command to obtain them.

I don't understand what you mean by this.

> > > > And what about all of the fixes I merge in, that _are_ really
> > > > security fixes, yet we do not want to shout it out to the world
> > > > at the moment?
> > > 
> > > For known security bugs, being aware of a fix earlier helps.
> > 
> > I don't understand what you mean here at all.
> 
> Neither do I understand what you mean by not shouting it out; so,
> unless you have argumentation to not shout it out, I'm in the belief
> that the faster one is able to apply a security fix, the more secure he
> is as a result. If not shouting it out makes things more secure, then
> please state me how and why; because it only gives attackers more time.

The kernel team does not explicitly call out security fixes when they go
into the kernel for a variety of good reasons, all of which have been
argued and debated numerous times for many years.  See the linux-kernel
mailing list archives if you are curious, I'm not going to get into that
argument here, except to point out that the current behavior is probably
not going to change.

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2256 bytes --]

On Fri, 9 Aug 2013 12:30:42 -0700
Greg KH <gregkh@gentoo.org> wrote:

> ...  Just read the commits to find out what is resolved, ...
>
> ... Because it's extra work that is pointless.  ...
> 
> > No classification is done if there is no single command to obtain
> > them.
> 
> I don't understand what you mean by this.

What I'm suggesting is based on the need for a digest; we both know,
that a lot of people are not going to read every single commit to
classify them, if everyone has to do that that causes a lot of double
work which could be easily spared out at the source. Alternatively,
we are in need of a separate resource outside of the kernel infra that
is interested in classifying commits this way, I'm not sure whether
there is anybody doing such thing.

Well, the CVE's are one such resource; but as you have stated in the
other mail they run behind on this, I think that other resources might
also be destined to run behind. Therefore I only see doing this at the
source to be a more solid approach that doesn't give attackers the
extra time while things stay unpatched; so, this a legitimate concern
for kernel mantainers in Gentoo as well as server admins in general.

Of course our discussion won't make this happen, because you oppose;
but I'll try to hear later with the kernel ML what their thoughts are.

> The kernel team does not explicitly call out security fixes when they
> go into the kernel for a variety of good reasons, all of which have
> been argued and debated numerous times for many years.  See the
> linux-kernel mailing list archives if you are curious, I'm not going
> to get into that argument here, except to point out that the current
> behavior is probably not going to change.

Okay, thanks for the clarifications; I'll try to look for them, failing
that I suspect people will refer me to them when I post the proposal.

Undoubtedly you heard thoughts similar to the above many times before;
but I'm new to this train of thoughts, so I'm unaware of those debates.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Fri, Aug 09, 2013 at 09:46:43PM +0200, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 12:30:42 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > ...  Just read the commits to find out what is resolved, ...
> >
> > ... Because it's extra work that is pointless.  ...
> > 
> > > No classification is done if there is no single command to obtain
> > > them.
> > 
> > I don't understand what you mean by this.
> 
> What I'm suggesting is based on the need for a digest; we both know,
> that a lot of people are not going to read every single commit to
> classify them, if everyone has to do that that causes a lot of double
> work which could be easily spared out at the source. Alternatively,
> we are in need of a separate resource outside of the kernel infra that
> is interested in classifying commits this way, I'm not sure whether
> there is anybody doing such thing.

There is not, and anyone who has tried to do such a thing quickly gave
up as it was a very difficult task.  But please, if you feel like you
can succeed where others have failed, please do so, I know a lot of
people would like someone to do this type of work for them.

> Undoubtedly you heard thoughts similar to the above many times before;
> but I'm new to this train of thoughts, so I'm unaware of those debates.

Yes, it comes up every few months by people who are just suddenly
thinking of it.  Please give us some kind of credit, we have been
dealing with this issue for well over a decade, and have come to the
existing state based on our experience and knowledge of what works best
for us, and hopefully, the rest of the community.

thanks,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

On Wed, 24 Jul 2013 21:01:30 +0200
Peter Stuge <peter@stuge.se> wrote:

> I am suggesting that the latest available upstream kernel should
> perhaps be the default for Gentoo users.

See my previous e-mail; if you're willing to go through with this
suggestion, then please back that up with sufficient reasoning. That
is, state what is bad with gentoo-sources and state the advantages that
would come with vanilla-sources; but don't forget to document the
disadvantages as well, since there is no magic silver bullet here.

Would you upgrade more than hundreds to thousands of servers to 3.10.0?

Take a look at the whole picture; for example, Nouveau worked great in
late 3.6 and regressed over a lot of people in early 3.7, so they had
to wait for fixes to land in late 3.7 again. Another example? Here:

https://bugs.gentoo.org/show_bug.cgi?id=468078#c0

And there thousands of bugs to find on all the bug trackers out there
that share this kind of nature; so, this is why you can't simple mark
what upstream deems stable, but rather what our QA process deems stable.

Changing that QA process doesn't happen from one day onto the other; it
has to be carefully thought out, documented, planned and announced.

If not, it could affect Gentoo's image.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

On Wed, 24 Jul 2013 19:54:10 +0200
Peter Stuge <peter@stuge.se> wrote:

> Rich Freeman wrote:
> > > As has been stated, this implies that Gentoo QA has tested the
> > > packages and found them to be reasonably safe for use.
> > 
> > ++
> 
> While good in theory, it seems that newer v-s are actually more
> "reasonably safe" than any g-s.

Depends; a version like 3.10.0 could introduce 0-days that might not get
fixed till 3.10.6, whereas a version like 3.9.11 received many fixes
and doesn't have these 0-days yet. Reasonably safe is subjective.

But that's just "safe" as in security, there's also "safe" as in
stable; versions like 3.10.0 - 3.10.2 come with a lot of rewrites, new
features and what not, a collection of stuff that was just written and
just passed the release candidate and stable queue. 3.10.0 breaks stuff.

Fixes for the introduced bugs will take a few more releases; that
3.10.3 that comes up? A whopping 100+ patches. Compare that to a version
like 3.9.11 that has not seen anything new and received lots of fixes.

This is why, for gentoo-sources, we pick kernels near the end of a
branch; they can be seen as more secure and stable than the latest
upstream stable kernel, especially since we backport important security
fixes. Like for instance has been seen with 3.7 and similar.

Now, you might wonder, why not stabilize 3.10.6 instead of waiting for
something like 3.10.12 that could be EOL? Well, while that is certainly
something we would like to do, and I have tried in the past; it didn't
work out because the stabilization teams are a bit undermanned to keep
up with stabilizing kernels this frequently. Don't forget there is
hardened-sources, you can see that they also have one kernel per
branch; their last stable kernel, awfully sits at 3.9.5. So...

Arch teams need more resources; as in man power and machine power.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Alex Xu wrote:
> > Maybe it would make sense to automatically stabilize every v-s kernel
> > right away?
> 
> As has been stated, this implies that Gentoo QA has tested the packages
> and found them to be reasonably safe for use.
..
> Although stable kernels *have* been tested by many people before use,
> Gentoo QA has *not* (officially) tested them, at least not on every
> architecture.

I don't think that matters.


> On a technical level, it's not that hard to put
> "sys-kernel/vanilla-sources" in your package.accept_keywords.

But why should Gentoo users have to do that in order to use v-s?

If it is intentional to push g-s onto users then it makes good sense -
but if I were the sys-kernel team I wouldn't bother with g-s at all
and just make v-s as easily available to users as possible..


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

On 24/07/13 01:49 PM, Peter Stuge wrote:
> Alex Xu wrote:
>>> Maybe it would make sense to automatically stabilize every v-s kernel
>>> right away?
>>
>> As has been stated, this implies that Gentoo QA has tested the packages
>> and found them to be reasonably safe for use.
> ..
>> Although stable kernels *have* been tested by many people before use,
>> Gentoo QA has *not* (officially) tested them, at least not on every
>> architecture.
> 
> I don't think that matters.

If you don't care too much for Gentoo QA, then you are free to run
global ~arch on your system. It works reasonably well (no sarcasm), and
almost always, someone has tested most packages on most architectures.
At least it's been tested by the programmer and maintainer. But that's
how KEYWORDS have always been used in Gentoo, as far as I know.

>> On a technical level, it's not that hard to put
>> "sys-kernel/vanilla-sources" in your package.accept_keywords.
> 
> But why should Gentoo users have to do that in order to use v-s?

So they acknowledge that vanilla-sources has not been officially tested
by Gentoo QA. You are free to do the simple procedure once and trust the
kernel community to have done adequate testing.

> If it is intentional to push g-s onto users then it makes good sense -
> but if I were the sys-kernel team I wouldn't bother with g-s at all
> and just make v-s as easily available to users as possible..

I can't comment on that.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

Alex Xu wrote:
> >>> Maybe it would make sense to automatically stabilize every v-s kernel
> >>> right away?
> >>
> >> As has been stated, this implies that Gentoo QA has tested the packages
> >> and found them to be reasonably safe for use.
> > ..
> >> Although stable kernels *have* been tested by many people before use,
> >> Gentoo QA has *not* (officially) tested them, at least not on every
> >> architecture.
> > 
> > I don't think that matters.
> 
> If you don't care too much for Gentoo QA

The point is that when arch teams find that they can not keep up with
the pace of upstream and choose never to attempt stabilize v-s then
clearly Gentoo QA will also not be able to keep up with that pace and
thus Gentoo QA becomes irrelevant for the particular package.

There will never be Gentoo QA on v-s.

The original post also mentioned that generally v-s has more fixes
than anything coming from stabilization efforts.

It seems that for this package Gentoo QA can not realistically add
any value to this package, hence my suggestion not to pretend that
they can, and just remove the distinction between ~arch and arch for
v-s, and make the latest version available to users by default.


> >> On a technical level, it's not that hard to put
> >> "sys-kernel/vanilla-sources" in your package.accept_keywords.
> > 
> > But why should Gentoo users have to do that in order to use v-s?
> 
> So they acknowledge that vanilla-sources has not been officially tested
> by Gentoo QA.

Since v-s is a special case that Gentoo QA is known not to handle,
this overhead seems completely unneccessary to me. And the usability
is of course poor.


> > If it is intentional to push g-s onto users then it makes good sense
..
> I can't comment on that.

I guess this is really the pivotal point. If Gentoo prefers to push
g-s rather than v-s then adding overhead for v-s kernels is fine. I'd
prefer Gentoo to push v-s instead.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 4010 bytes --]

On Wed, 24 Jul 2013 20:16:59 +0200
Peter Stuge <peter@stuge.se> wrote:

> Alex Xu wrote:
> > >>> Maybe it would make sense to automatically stabilize every v-s
> > >>> kernel right away?
> > >>
> > >> As has been stated, this implies that Gentoo QA has tested the
> > >> packages and found them to be reasonably safe for use.
> > > ..
> > >> Although stable kernels *have* been tested by many people before
> > >> use, Gentoo QA has *not* (officially) tested them, at least not
> > >> on every architecture.
> > > 
> > > I don't think that matters.
> > 
> > If you don't care too much for Gentoo QA
> 
> The point is that when arch teams find that they can not keep up with
> the pace of upstream and choose never to attempt stabilize v-s then
> clearly Gentoo QA will also not be able to keep up with that pace and
> thus Gentoo QA becomes irrelevant for the particular package.

No, stabilization of vanilla-sources would be an addition in work
required; one can not assume that if gentoo-sources is stable than
vanilla-sources is or vice versa. Also, the premise here is that
vanilla-sources would need to be stabilized every version; and not just
once per branch (we would like two or three though) as gentoo-sources.

> The original post also mentioned that generally v-s has more fixes
> than anything coming from stabilization efforts.

More fixes; but also more regressions, new features, more 0-days, ...

> It seems that for this package Gentoo QA can not realistically add
> any value to this package, hence my suggestion not to pretend that
> they can, and just remove the distinction between ~arch and arch for
> v-s, and make the latest version available to users by default.

That's a contradiction; their added value is it being deemed stable,
they can't just pretend it is stable, that overrides the distinction.

For as far that I know there is nowhere in the tree we provide matters
that walk past Gentoo; so, why should they make an exception here?

> > >> On a technical level, it's not that hard to put
> > >> "sys-kernel/vanilla-sources" in your package.accept_keywords.
> > > 
> > > But why should Gentoo users have to do that in order to use v-s?
> > 
> > So they acknowledge that vanilla-sources has not been officially
> > tested by Gentoo QA.
> 
> Since v-s is a special case that Gentoo QA is known not to handle,
> this overhead seems completely unneccessary to me. And the usability
> is of course poor.

If Gentoo QA can't handle it, why could our users; if they are to make
a poor sense of stability, that suffices to make it an explicit choice.

> > > If it is intentional to push g-s onto users then it makes good
> > > sense
> ..
> > I can't comment on that.
> 
> I guess this is really the pivotal point. If Gentoo prefers to push
> g-s rather than v-s then adding overhead for v-s kernels is fine. I'd
> prefer Gentoo to push v-s instead.

If this weren't intentional, we wouldn't be doing this; the kernel team
exists to add value and not just to blindly follow upstream.

Let me quote the project description:

"With an ever increasing userbase demanding a higher quality of stable,
production-ready kernel sources and featureful desktop support the
professionalism and staffing of the kernel project is very important.

Because we as users want the best from Gentoo Linux we supply a
selection of both generic and specialised sources capable of handling
the day-to-day grind to make life a little easier.

In order to provide a rich choice of high quality kernel trees Gentoo
Linux must apply, write and test several kernel patches to the official
upstream releases before they can offer finished ebuilds to the users.
This is where the Gentoo Kernel project comes into play."

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Markos Chandras]

On 24 July 2013 21:59, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Wed, 24 Jul 2013 20:16:59 +0200
> Peter Stuge <peter@stuge.se> wrote:
>
>> Alex Xu wrote:
>> > >>> Maybe it would make sense to automatically stabilize every v-s
>> > >>> kernel right away?
>> > >>
>> > >> As has been stated, this implies that Gentoo QA has tested the
>> > >> packages and found them to be reasonably safe for use.
>> > > ..
>> > >> Although stable kernels *have* been tested by many people before
>> > >> use, Gentoo QA has *not* (officially) tested them, at least not
>> > >> on every architecture.
>> > >
>> > > I don't think that matters.
>> >
>> > If you don't care too much for Gentoo QA
>>
>> The point is that when arch teams find that they can not keep up with
>> the pace of upstream and choose never to attempt stabilize v-s then
>> clearly Gentoo QA will also not be able to keep up with that pace and
>> thus Gentoo QA becomes irrelevant for the particular package.
>
> No, stabilization of vanilla-sources would be an addition in work
> required; one can not assume that if gentoo-sources is stable than
> vanilla-sources is or vice versa. Also, the premise here is that
> vanilla-sources would need to be stabilized every version; and not just
> once per branch (we would like two or three though) as gentoo-sources.
>
>> The original post also mentioned that generally v-s has more fixes
>> than anything coming from stabilization efforts.
>
> More fixes; but also more regressions, new features, more 0-days, ...
>
>> It seems that for this package Gentoo QA can not realistically add
>> any value to this package, hence my suggestion not to pretend that
>> they can, and just remove the distinction between ~arch and arch for
>> v-s, and make the latest version available to users by default.
>
> That's a contradiction; their added value is it being deemed stable,
> they can't just pretend it is stable, that overrides the distinction.
>
> For as far that I know there is nowhere in the tree we provide matters
> that walk past Gentoo; so, why should they make an exception here?
>
>> > >> On a technical level, it's not that hard to put
>> > >> "sys-kernel/vanilla-sources" in your package.accept_keywords.
>> > >
>> > > But why should Gentoo users have to do that in order to use v-s?
>> >
>> > So they acknowledge that vanilla-sources has not been officially
>> > tested by Gentoo QA.
>>
>> Since v-s is a special case that Gentoo QA is known not to handle,
>> this overhead seems completely unneccessary to me. And the usability
>> is of course poor.
>
> If Gentoo QA can't handle it, why could our users; if they are to make
> a poor sense of stability, that suffices to make it an explicit choice.
>
>> > > If it is intentional to push g-s onto users then it makes good
>> > > sense
>> ..
>> > I can't comment on that.
>>
>> I guess this is really the pivotal point. If Gentoo prefers to push
>> g-s rather than v-s then adding overhead for v-s kernels is fine. I'd
>> prefer Gentoo to push v-s instead.
>
> If this weren't intentional, we wouldn't be doing this; the kernel team
> exists to add value and not just to blindly follow upstream.
>
> Let me quote the project description:
>
> "With an ever increasing userbase demanding a higher quality of stable,
> production-ready kernel sources and featureful desktop support the
> professionalism and staffing of the kernel project is very important.
>
> Because we as users want the best from Gentoo Linux we supply a
> selection of both generic and specialised sources capable of handling
> the day-to-day grind to make life a little easier.
>
> In order to provide a rich choice of high quality kernel trees Gentoo
> Linux must apply, write and test several kernel patches to the official
> upstream releases before they can offer finished ebuilds to the users.
> This is where the Gentoo Kernel project comes into play."
>
> --
> With kind regards,
>
> Tom Wijsman (TomWij)
> Gentoo Developer
>
> E-mail address  : TomWij@gentoo.org
> GPG Public Key  : 6D34E57D
> GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

This thread derailed as usual.

The kernel team made a decision. We can simply accept it and move on.
Stable keywords imply at least a minimal build and runtime testing by
arch teams.
Since we have no manpower to do it, then stabilizing them blindly is
not appropriate.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Wed, 24 Jul 2013 23:17:36 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:

> This thread derailed as usual. The kernel team made a decision.

Perhaps it did, perhaps it didn't; I do not intend to discuss this but
to rather clarify the decision that was made, as a matter of support.
The reason the reply was on the ML is so it benefits more people.

Granted, the ML isn't the right place for support though; if anyone
has further doubts we invite them to mail the kernel herd about it.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

24.07.2013 22:16, Peter Stuge пишет:
> It seems that for this package Gentoo QA can not realistically add
> any value to this package, hence my suggestion not to pretend that
> they can, and just remove the distinction between ~arch and arch for
> v-s, and make the latest version available to users by default.

As were said before, blindly stabling vanilla-sources when
gentoo-sources is stabilized is not an option.

"Remove the distinction between ~arch and arch" for any package is not
apropriate, as stable keywords were made for a reason, period...

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Chí-Thanh Christopher Nguyễn]

Mike Pagano schrieb:
> Team members working alongside upstream (and downstream) developer Greg k-h 
> have decided to no longer request stabilization of the vanilla sources kernel.  

How about dropping vanilla-sources and adding a "vanilla" USE flag to
gentoo-sources?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
> How about dropping vanilla-sources and adding a "vanilla" USE flag 
> to gentoo-sources?
Then we might as well just have a Linux package with a bunch of USE
flags -- gentoo, hardened, libre, tuxonice, ck, etc.
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlHzyugACgkQRtClrXBQc7VyjwD/WXn+JxvCukvY1xkpQzYnwm9N
frXlmNbvh8ic0K5dxw4A+gMoly44UzLBNoMlFdp4dGqVjCHv6sMnw7p0zcDc0cO1
=qgEa
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Manuel Rüger]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
> On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
>> How about dropping vanilla-sources and adding a "vanilla" USE flag 
>> to gentoo-sources?
> Then we might as well just have a Linux package with a bunch of USE
> flags -- gentoo, hardened, libre, tuxonice, ck, etc.
> 

This is not a good idea, I'd like to have different kernel flavours of
the same version installed in parallel.

Kind regards,

Manuel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1031 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/07/13 15:32, Manuel Rüger wrote:
> On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
>> Then we might as well just have a Linux package with a bunch of 
>> USE flags -- gentoo, hardened, libre, tuxonice, ck, etc.
> This is not a good idea, I'd like to have different kernel
> flavours of the same version installed in parallel.

On 27/07/13 20:20, Chí-Thanh Christopher Nguyễn wrote:
> I don't think this can be made work, the other kernel packages' 
> releases may not happen simultaneously with kernel releases. Or
> they may even skip certain releases.

Sorry, the point I was trying to make was basically that I think that
using a "vanilla" USE flag is a bad idea.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlH24nsACgkQRtClrXBQc7UfUAEAr465o/VCLPTvYLMEQ4aZMO9S
8b6HyeAqYp1HRVgg5usBAK4n4j2hgw/6JzFFfEJyOZWIvWC4tEQyffj8p62BP35/
=64DS
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]

On Sat, 27 Jul 2013 15:32:39 +0200
Manuel Rüger <mrueg@gentoo.org> wrote:

> On 07/27/2013 03:28 PM, Alexander Berntsen wrote:
> > On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
> >> How about dropping vanilla-sources and adding a "vanilla" USE flag 
> >> to gentoo-sources?
> > Then we might as well just have a Linux package with a bunch of USE
> > flags -- gentoo, hardened, libre, tuxonice, ck, etc.
> > 
> 
> This is not a good idea, I'd like to have different kernel flavours of
> the same version installed in parallel.

If people think both ideas are good, consider having both?

Adding USE flags without dropping the packages is also an option; the
mere reason we will be bringing the experimental patches [1] soon is to
spare out on some of the duplicate work that is being done, if people
want to continue to maintain a separate package then nothing prohibits
them from doing so. Not the experimental patches [1] idea, and not the
addition of USE flags.

That being said, I expressed earlier that USE flags feel like a bad
idea though; I want you to keep in mind that, if you add USE flags, you
effectively have a double opt-in since you need to enable the USE flag
and then after that toggle the options in the menuconfig as well.

Is the gain of adding USE flags really worth the burden it causes?

 [1]: http://article.gmane.org/gmane.linux.gentoo.kernel/740

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Chí-Thanh Christopher Nguyễn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Berntsen schrieb:
> On 27/07/13 10:56, Chí-Thanh Christopher Nguyễn wrote:
>> How about dropping vanilla-sources and adding a "vanilla" USE flag to
>> gentoo-sources?
> Then we might as well just have a Linux package with a bunch of USE 
> flags -- gentoo, hardened, libre, tuxonice, ck, etc.

I don't think this can be made work, the other kernel packages' releases
may not happen simultaneously with kernel releases. Or they may even skip
certain releases.

Rich Freeman schrieb:
> Unless it were stable-masked it would create the exact same problem.

vanilla flags are not package.use.stable.mask'ed for toolchain packages
either, yet they go stable with them. And there, USE=vanilla might cause
serious breakage even.

> There was another suggestion to try to manage the patch sets via the 
> kernel config system, but that isn't without its own challenges.

vanilla = don't apply any patches, I don't think that could be improved by
any modification to the kernel config system.


Best regards,
Chí-Thanh Christopher Nguyễn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlH0D3MACgkQ+gvH2voEPRBmFACbBixGjRbW0z4yOhMvLRXaHx1z
PjAAnin5cF6lD7X8n0KGpBbyMFT3kAAz
=kPOS
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Rich Freeman]

On Sat, Jul 27, 2013 at 4:56 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Mike Pagano schrieb:
>> Team members working alongside upstream (and downstream) developer Greg k-h
>> have decided to no longer request stabilization of the vanilla sources kernel.
>
> How about dropping vanilla-sources and adding a "vanilla" USE flag to
> gentoo-sources?

Unless it were stable-masked it would create the exact same problem.

There was another suggestion to try to manage the patch sets via the
kernel config system, but that isn't without its own challenges.

Rich

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Mike Pagano]

On Saturday, July 27, 2013 09:58:08 AM Rich Freeman wrote:

> 
> Unless it were stable-masked it would create the exact same problem.
> 


^^ This

-- 
Mike Pagano
Gentoo Developer - Kernel Project
E-Mail     : mpagano@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