On Fri, Aug 09, 2013 at 09:46:43PM +0200, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 12:30:42 -0700
> Greg KH 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 sing
On Fri, 9 Aug 2013 12:30:42 -0700
Greg KH 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.
On Fri, Aug 09, 2013 at 10:34:58AM +0200, Tom Wijsman wrote:
> On Thu, 8 Aug 2013 15:32:45 -0700
> Greg KH 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 wrote:
> > >
> > > > I am not going to impose an additional
On Fri, Aug 09, 2013 at 03:28:54PM +0200, Tom Wijsman wrote:
> On Fri, 9 Aug 2013 06:38:56 -0400
> Rich Freeman 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
On Fri, 9 Aug 2013 06:38:56 -0400
Rich Freeman 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
On Fri, Aug 9, 2013 at 4:34 AM, Tom Wijsman wrote:
> On Thu, 8 Aug 2013 15:32:45 -0700
> Greg KH 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
On Thu, 8 Aug 2013 15:32:45 -0700
Greg KH 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 wrote:
> >
> > > I am not going to impose an additional burden on developers to get
> > > their patches into the stable kernel releas
On Fri, 9 Aug 2013 01:44:12 +0200
Peter Stuge 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
On Thu, 8 Aug 2013 15:29:06 -0700
Greg KH 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.
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 kerne
On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
> On Wed, 7 Aug 2013 15:44:34 -0700
> Greg KH 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
On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
> On Wed, 7 Aug 2013 16:19:43 -0700
> Greg KH 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
On Wed, 7 Aug 2013 16:19:43 -0700
Greg KH 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
On Wed, 7 Aug 2013 15:44:34 -0700
Greg KH 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
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
> t
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 "sec
On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
> On Wed, 24 Jul 2013 16:09:11 -0700
> Greg KH 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 wit
On Sat, 27 Jul 2013 15:32:39 +0200
Manuel Rüger 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 hav
On Wed, 24 Jul 2013 23:17:36 +0100
Markos Chandras 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
On Wed, 24 Jul 2013 16:09:11 -0700
Greg KH 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
-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
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 : mpag...@gentoo.org
GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3
Publi
-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
> fl
On Sat, Jul 27, 2013 at 4:56 AM, Chí-Thanh Christopher Nguyễn
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 an
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,
-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, tu
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
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
On Wed, Jul 24, 2013 at 7:09 PM, Greg KH 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,
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
On 24 July 2013 21:59, Tom Wijsman wrote:
> On Wed, 24 Jul 2013 20:16:59 +0200
> 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 th
On Wed, 24 Jul 2013 20:16:59 +0200
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 saf
On Wed, 24 Jul 2013 16:40:38 -0400
Rich Freeman 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
On Wed, 24 Jul 2013 21:15:15 +0200
Peter Stuge 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 c
On Wed, Jul 24, 2013 at 3:15 PM, Peter Stuge 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 bre
On Wed, 24 Jul 2013 21:01:30 +0200
Peter Stuge 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. Th
On Wed, 24 Jul 2013 19:54:10 +0200
Peter Stuge 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
> "reasona
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
On Wed, Jul 24, 2013 at 2:01 PM, Peter Stuge 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 automat
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 re
On Wed, Jul 24, 2013 at 1:54 PM, Peter Stuge 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 i
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
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
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, sta
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
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 th
On Wed, Jul 24, 2013 at 1:43 PM, Alex Xu 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 ea
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
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
49 matches
Mail list logo
