[Ksummit-discuss] [MAINTAINERS SUMMIT] Deprecation / Removal of old hardware support

[Daniel Vetter]

On Tue, Sep 11, 2018 at 8:27 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> On Tue, Sep 11, 2018 at 07:58:48PM +0200, Geert Uytterhoeven wrote:
>> Hi Günter,
>>
>> On Tue, Sep 11, 2018 at 7:27 PM Guenter Roeck <linux at roeck-us.net> wrote:
>> > On Tue, Sep 11, 2018 at 10:49:25AM +0200, Geert Uytterhoeven wrote:
>> > > On Tue, Sep 11, 2018 at 12:02 AM Guenter Roeck <linux at roeck-us.net> wrote:
>> > > > On Mon, Sep 10, 2018 at 11:40:59PM +0200, Arnd Bergmann wrote:
>> > > > > One architecture (unicore32) got saved in the last minute by
>> > > > > the maintainer saying that he'd rather keep it in tree, despite not
>> > > > > even having a publicly available toolchain with sources.
>> > > >
>> > > > unicore32 no longer builds with the mainline kernel because the
>> > > > (private) toolchain is too old (gcc < 4.6), so it may be time
>> > > > to revisit that decision.
>> > >
>> > > I'm still building mainline with gcc-4.1.2, using:
>> > >
>> > >     git revert 815f0ddb346c1960 # "include/linux/compiler*.h: make
>> > > compiler-*.h mutually exclusive"
>> > >     git revert cafa0010cd51fb71 # "Raise the minimum required gcc
>> > > version to 4.6"
>> > >
>> > > leading to one recent bug fix:
>> > >
>> > >     https://lore.kernel.org/lkml/20180823212738.18431-1-geert@linux-m68k.org/
>> > >
>> > > and two code improvements:
>> > >
>> > >     https://lore.kernel.org/lkml/20180823212436.17423-1-geert@linux-m68k.org/
>> > >     https://lore.kernel.org/lkml/20180823213027.18856-1-geert@linux-m68k.org/
>> >
>> > Interesting. How to you manage to not hit the problem reported with
>> > https://lkml.org/lkml/2018/8/14/472 ?
>>
>> Sorry, I forgot I have also applied Andrew's wibble patch:
>> https://lore.kernel.org/lkml/20180814160208.4f4dd7ca142912f5894ddddd@linux-foundation.org/
>>
>
> Hmm. I don't really want to have to maintain a set of patches on top upstream
> and stable kernels to be able to run my tests. I do have a set of configuration
> options to apply, but anything beyond that is, in my opinion, out of scope
> for (at least my) testing.

We've given that notion up years ago :-/

There's a constantly included topic branch with hacks-for-CI with a
random assortment of reverts, patches stuck in forever-limbo and
things where we've been yelled at too much and it's just not worth the
bother. If our CI is down, there's a 50 people team becoming rapidly
unhappy, we can't affort to wait even for maintainers who are on top
of their stuff. Rapidly here means: a few hours after CI is
down/backlogged, it's the only topic on our irc channel.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch