Re: [arch-general] About linux 4.8 and 4.9...

2017-01-10 Thread Genes Lists via arch-general
On Tue, 2017-01-10 at 16:55 +, Mike Cloaked via arch-general wrote:
> On Tue, Jan 10, 2017 at 1:53 PM, Carsten Mattner via arch-general <
> arch-general@archlinux.org> wrote:
> 
> > ...
> > 
> 
> Looks like there are some patches to try and are being tested for
> kernel
> 4.9 - see https://bugzilla.kernel.org/show_bug.cgi?id=191121
> 

For me this is an EFI issue introduced in 4.9-rc1 - as described in
https://bugzilla.kernel.org/show_bug.cgi?id=191801
https://bugzilla.kernel.org/show_bug.cgi?id=191121

the EFI patch applied to 4.10-rc3 is now bootable again. I need to test
4.9.2 as well but am pretty sure this will work too.

I will note that not everyone having issues is using efi - so there
could well be more than one issue involved here.

regards,


-- 
Gene
li...@sapience.com


Re: [arch-general] About linux 4.8 and 4.9...

2017-01-10 Thread Carsten Mattner via arch-general
On Tue, Jan 10, 2017 at 8:14 PM, Eli Schwartz via arch-general wrote:
> On 01/10/2017 08:53 AM, Carsten Mattner via arch-general wrote:
>> My criticism of the stable patch queue is that they mix fixes
>> with actual feature patches, making it more risky and not
>> upholding a important fixes only policy.
>
> That would depend on whether you understand "stable" to be "LTS" or
> "let's not just pile on all the experimental stuff that may break
> everything".

Since drivers are bundled in the kernel tree, we regularly run into
many driver regressions and that's my primary objection to the
missing quality assurance there. The community is doing an
outstanding amount of testing already but the ranger of supported
hardware is not covered by the testers and constant churn of code
because it's part of a moving amalgamation in linux.git causes more
issues than we would have with drivers targering a kernel ABI.
One thing it would help make abundantly clear is when a driver
maintainer stops supporting an old driver version. Now it's russian
roulette for hardware to break when updating from one stable to
the next supported stable kernel. Like it happened with 4.2 in DRM
or the 4.9 boot problems which seem to be UEFI-exclusive.

> I am pretty sure there is already, in fact, an LTS kernel. You even
> mentioned it yourself.

There are multiple LTS branches with one LTS being Greg's tree.


Re: [arch-general] About linux 4.8 and 4.9...

2017-01-10 Thread Eli Schwartz via arch-general
On 01/10/2017 08:53 AM, Carsten Mattner via arch-general wrote:
> My criticism of the stable patch queue is that they mix fixes
> with actual feature patches, making it more risky and not
> upholding a important fixes only policy.

That would depend on whether you understand "stable" to be "LTS" or
"let's not just pile on all the experimental stuff that may break
everything".

I am pretty sure there is already, in fact, an LTS kernel. You even
mentioned it yourself.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] About linux 4.8 and 4.9...

2017-01-10 Thread Mike Cloaked via arch-general
On Tue, Jan 10, 2017 at 1:53 PM, Carsten Mattner via arch-general <
arch-general@archlinux.org> wrote:

> FYI, 4.8 has been EOL'd, leaving 4.4-lts, 4.1-lts as options for
> arch "default" kernel until 4.10 is released if we assume that
> there's a critical fix in the stable patch queue.
>
> My criticism of the stable patch queue is that they mix fixes
> with actual feature patches, making it more risky and not
> upholding a important fixes only policy.
>

Looks like there are some patches to try and are being tested for kernel
4.9 - see https://bugzilla.kernel.org/show_bug.cgi?id=191121

-- 
mike c


Re: [arch-general] About linux 4.8 and 4.9...

2017-01-10 Thread Carsten Mattner via arch-general
FYI, 4.8 has been EOL'd, leaving 4.4-lts, 4.1-lts as options for
arch "default" kernel until 4.10 is released if we assume that
there's a critical fix in the stable patch queue.

My criticism of the stable patch queue is that they mix fixes
with actual feature patches, making it more risky and not
upholding a important fixes only policy.