From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <20180911182706.GB21160@roeck-us.net> References: <20180910220208.GB17966@roeck-us.net> <20180911172741.GA2767@roeck-us.net> <20180911182706.GB21160@roeck-us.net> From: Daniel Vetter Date: Tue, 11 Sep 2018 20:37:22 +0200 Message-ID: To: Guenter Roeck Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Deprecation / Removal of old hardware support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Sep 11, 2018 at 8:27 PM, Guenter Roeck wrote: > On Tue, Sep 11, 2018 at 07:58:48PM +0200, Geert Uytterhoeven wrote: >> Hi G=C3=BCnter, >> >> On Tue, Sep 11, 2018 at 7:27 PM Guenter Roeck 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 = 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@lin= ux-foundation.org/ >> > > Hmm. I don't really want to have to maintain a set of patches on top upst= ream > and stable kernels to be able to run my tests. I do have a set of configu= ration > options to apply, but anything beyond that is, in my opinion, out of scop= e > 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 --=20 Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch