From: Christoph Hellwig <hch@infradead.org> To: Rich Felker <dalias@libc.org> Cc: Christoph Hellwig <hch@infradead.org>, Arnd Bergmann <arnd@arndb.de>, linux-sh@vger.kernel.org, ysato@users.sourceforge.jp, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, Rob Landley <rob@landley.net>, Geert Uytterhoeven <geert@linux-m68k.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [GIT PULL] sh: remove sh5 support Date: Fri, 29 May 2020 14:35:15 +0000 [thread overview] Message-ID: <20200529143515.GB25475@infradead.org> (raw) In-Reply-To: <20200528221450.GF1079@brightrain.aerifal.cx> On Thu, May 28, 2020 at 06:14:51PM -0400, Rich Felker wrote: > To follow up, I see that there was a patch series of yours (3/24) I > missed ack'ing fairly recently. At first glance it looks good. Well, I need a formal ACK, or even better have the arch maintainer pick it up, as that is how development is normally supposed to work. > In general, most of the patches I see are things that the linux-sh > list and myself end up cc'd on that are only tangentially related to > arch/sh or even not related at all. In that case I normally trust > other maintainers familiar with the cross-arch changes being made that > the small arch/sh part of the change is ok if the broader change is > abstractly ok. FYI, if you want to reduce the amount of crap you get Cced on, you can add yourself to .get_maintainer.ignore file in the kernel tree, as that at least removes a lot of the pass by cleanups found from git log. > Part of why I really disliked the "just kill it all" response to this > thread is that the sh5 removal is specifically for the sake of making > the arch more maintainable. That, along with forward-porting Sato's > SH4 device tree patches (I've tried this but ran into problems, and > need some help with it), has long been on my agenda for the arch, to > reduce (and ultimately eliminate) the amount of legacy "only on > arch/sh" stuff left so that it's not a burden on other maintainers and > contributors. Seeing sentiment along the lines of "why don't you just > remove it all while you're at it?" as a response is disheartening and > also dismissive of Arnd's work making the sh5 removal happen. We had the discussion before and things like the sh5 removal and device tree switch came out of it. But since then exactly nothing has happened - the arch code is still pretty much unmaintained and impossible to get a review for. No one expects super quick responses for a legacy architecture, but if there is no way to get feedback or patches queued up while the code keeps on bitrotting the architecture is effectively dead. I have no personal problem with the sh hardware, but if we want a Linux port to survive it will need at least a minimum amount of active maintainance.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Rich Felker <dalias@libc.org> Cc: Christoph Hellwig <hch@infradead.org>, Arnd Bergmann <arnd@arndb.de>, linux-sh@vger.kernel.org, ysato@users.sourceforge.jp, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, Rob Landley <rob@landley.net>, Geert Uytterhoeven <geert@linux-m68k.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [GIT PULL] sh: remove sh5 support Date: Fri, 29 May 2020 07:35:15 -0700 [thread overview] Message-ID: <20200529143515.GB25475@infradead.org> (raw) In-Reply-To: <20200528221450.GF1079@brightrain.aerifal.cx> On Thu, May 28, 2020 at 06:14:51PM -0400, Rich Felker wrote: > To follow up, I see that there was a patch series of yours (3/24) I > missed ack'ing fairly recently. At first glance it looks good. Well, I need a formal ACK, or even better have the arch maintainer pick it up, as that is how development is normally supposed to work. > In general, most of the patches I see are things that the linux-sh > list and myself end up cc'd on that are only tangentially related to > arch/sh or even not related at all. In that case I normally trust > other maintainers familiar with the cross-arch changes being made that > the small arch/sh part of the change is ok if the broader change is > abstractly ok. FYI, if you want to reduce the amount of crap you get Cced on, you can add yourself to .get_maintainer.ignore file in the kernel tree, as that at least removes a lot of the pass by cleanups found from git log. > Part of why I really disliked the "just kill it all" response to this > thread is that the sh5 removal is specifically for the sake of making > the arch more maintainable. That, along with forward-porting Sato's > SH4 device tree patches (I've tried this but ran into problems, and > need some help with it), has long been on my agenda for the arch, to > reduce (and ultimately eliminate) the amount of legacy "only on > arch/sh" stuff left so that it's not a burden on other maintainers and > contributors. Seeing sentiment along the lines of "why don't you just > remove it all while you're at it?" as a response is disheartening and > also dismissive of Arnd's work making the sh5 removal happen. We had the discussion before and things like the sh5 removal and device tree switch came out of it. But since then exactly nothing has happened - the arch code is still pretty much unmaintained and impossible to get a review for. No one expects super quick responses for a legacy architecture, but if there is no way to get feedback or patches queued up while the code keeps on bitrotting the architecture is effectively dead. I have no personal problem with the sh hardware, but if we want a Linux port to survive it will need at least a minimum amount of active maintainance.
next prev parent reply other threads:[~2020-05-29 14:35 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-24 22:19 [GIT PULL] sh: remove sh5 support Arnd Bergmann 2020-04-24 22:19 ` Arnd Bergmann 2020-04-24 22:19 ` [PATCH 1/1] " Arnd Bergmann 2020-04-24 22:19 ` Arnd Bergmann 2020-05-07 14:35 ` [GIT PULL] " Christoph Hellwig 2020-05-07 14:35 ` Christoph Hellwig 2020-05-28 5:46 ` Christoph Hellwig 2020-05-28 5:46 ` Christoph Hellwig 2020-05-28 5:55 ` John Paul Adrian Glaubitz 2020-05-28 5:55 ` John Paul Adrian Glaubitz 2020-05-28 9:40 ` Rob Landley 2020-05-28 9:40 ` Rob Landley 2020-05-28 16:14 ` Rich Felker 2020-05-28 16:14 ` Rich Felker 2020-05-28 22:14 ` Rich Felker 2020-05-28 22:14 ` Rich Felker 2020-05-28 22:28 ` Rob Landley 2020-05-28 22:28 ` Rob Landley 2020-05-28 22:32 ` John Paul Adrian Glaubitz 2020-05-28 22:32 ` John Paul Adrian Glaubitz 2020-05-28 22:37 ` Rich Felker 2020-05-28 22:37 ` Rich Felker 2020-05-29 14:35 ` Christoph Hellwig [this message] 2020-05-29 14:35 ` Christoph Hellwig 2020-05-29 14:30 ` Christoph Hellwig 2020-05-29 14:30 ` Christoph Hellwig 2020-05-29 17:53 ` Rich Felker 2020-05-29 17:53 ` Rich Felker 2020-05-29 18:22 ` Christoph Hellwig 2020-05-29 18:22 ` Christoph Hellwig 2020-05-30 8:08 ` John Paul Adrian Glaubitz 2020-05-30 8:08 ` John Paul Adrian Glaubitz 2020-05-30 8:47 ` Geert Uytterhoeven 2020-05-30 8:47 ` Geert Uytterhoeven 2020-05-31 3:20 ` Rob Landley 2020-05-31 3:20 ` Rob Landley 2020-05-31 8:03 ` John Paul Adrian Glaubitz 2020-05-31 8:03 ` John Paul Adrian Glaubitz 2020-06-01 2:55 ` Rich Felker 2020-06-01 2:55 ` Rich Felker 2020-06-01 8:16 ` John Paul Adrian Glaubitz 2020-06-01 8:16 ` John Paul Adrian Glaubitz 2020-06-01 18:13 ` Rich Felker 2020-06-01 18:13 ` Rich Felker 2020-06-01 21:12 ` Arnd Bergmann 2020-06-01 21:12 ` Arnd Bergmann 2020-06-02 1:33 ` Rich Felker 2020-06-02 1:33 ` Rich Felker 2020-06-02 2:49 ` Andrew Morton 2020-06-02 2:49 ` Andrew Morton 2020-06-02 2:53 ` Rich Felker 2020-06-02 2:53 ` Rich Felker 2020-06-03 7:27 ` John Paul Adrian Glaubitz 2020-06-03 7:27 ` John Paul Adrian Glaubitz 2020-06-03 7:31 ` John Paul Adrian Glaubitz 2020-06-03 7:31 ` John Paul Adrian Glaubitz 2020-06-05 15:38 ` John Paul Adrian Glaubitz 2020-06-05 15:38 ` John Paul Adrian Glaubitz 2020-06-05 15:43 ` Rich Felker 2020-06-05 15:43 ` Rich Felker 2020-06-05 15:47 ` John Paul Adrian Glaubitz 2020-06-05 15:47 ` John Paul Adrian Glaubitz 2020-06-05 15:59 ` Rich Felker 2020-06-05 15:59 ` Rich Felker 2020-06-05 17:58 ` John Paul Adrian Glaubitz 2020-06-05 17:58 ` John Paul Adrian Glaubitz 2020-06-05 18:23 ` Geert Uytterhoeven 2020-06-05 18:23 ` Geert Uytterhoeven 2020-06-06 0:50 ` Andrew Morton 2020-06-06 0:50 ` Andrew Morton
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200529143515.GB25475@infradead.org \ --to=hch@infradead.org \ --cc=arnd@arndb.de \ --cc=dalias@libc.org \ --cc=geert@linux-m68k.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=rob@landley.net \ --cc=torvalds@linux-foundation.org \ --cc=viro@zeniv.linux.org.uk \ --cc=ysato@users.sourceforge.jp \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.