All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Arnd Bergmann <arnd@arndb.de>, Tony Luck <tony.luck@intel.com>,
	Jessica Clarke <jrtc27@jrtc27.com>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Matthew Wilcox <willy@infradead.org>,
	Marc Zyngier <maz@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC PATCH] MAINTAINERS: Mark Itanium/IA64 as 'dead'
Date: Wed, 15 Feb 2023 09:08:15 -0800	[thread overview]
Message-ID: <20230215170815.GA3787950@roeck-us.net> (raw)
In-Reply-To: <CAMj1kXEnoghSNpQFucmSCEhG3s_nyBCm+btgLHzOTiU56=XPfQ@mail.gmail.com>

On Wed, Feb 15, 2023 at 04:40:30PM +0100, Ard Biesheuvel wrote:
> On Wed, 15 Feb 2023 at 16:15, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Sat, Jan 28, 2023 at 01:29:04PM +0100, Ard Biesheuvel wrote:
> > > Create a new status 'dead' which conveys that a subsystem is
> > > unmaintained and scheduled for removal, and developers are free to
> > > behave as if it's already gone. Also, automated build tests should
> > > ignore such subsystems, or at least notify only those who are known to
> > > have an interest in the subsystem in particular.
> > >
> > > Given that Itanium/IA64 has no maintainer, is no longer supported in
> > > QEMU (for boot testing under emulation) and does not seem to have a user
> > > base beyond a couple of machines used by distros to churn out packages,
> > > let's mark it as dead. This shall mean that any treewide changes (such
> > > as changes to the EFI subsystem, which I maintain) can be made even if
> > > they might cause build or boot time regressions on IA64 machines. Also,
> > > mark the port as scheduled for removal after the next LTS release.
> > >
> >
> > Since this just came up, I very much prefer complete removal. I don't
> > see the point of keeping dead code in the tree. That is still hidden
> > maintenance effort.
> >
> 
> Can I take this as an ack on
> 
> https://lore.kernel.org/linux-kernel/20230215100008.2565237-1-ardb@kernel.org/
>

I would not have considered myself important enough to make such a call,
but from a testbed maintainer's perspective it is an enthusiastic yes.

At the same time, again from a testbed maintainer's perspective,
introducing a new "dead" state into the code base deserves a just as
enthusiastic NACK.

Thanks,
Guenter


> ?
> 
> > If this proliferates, we'll end up having to parse the MAINTAINERS file
> > for code marked "Dead" to ensure that we don't accidentally send e-mails
> > to the wrong people, or we risk getting complaints about sending reports
> > for such code. That puts extra burden on maintainers of automated test
> > beds, which I think is not really appropriate. If the code is dead,
> > remove it, period.
> >
> > For my part, I'll drop my test bed support immediately after this patch
> > made it in, following the guidance above.
> >
> 
> Thanks for the insight. I think we should take the immediate removal route.

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Arnd Bergmann <arnd@arndb.de>, Tony Luck <tony.luck@intel.com>,
	Jessica Clarke <jrtc27@jrtc27.com>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Matthew Wilcox <willy@infradead.org>,
	Marc Zyngier <maz@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC PATCH] MAINTAINERS: Mark Itanium/IA64 as 'dead'
Date: Wed, 15 Feb 2023 17:08:15 +0000	[thread overview]
Message-ID: <20230215170815.GA3787950@roeck-us.net> (raw)
In-Reply-To: <CAMj1kXEnoghSNpQFucmSCEhG3s_nyBCm+btgLHzOTiU56=XPfQ@mail.gmail.com>

On Wed, Feb 15, 2023 at 04:40:30PM +0100, Ard Biesheuvel wrote:
> On Wed, 15 Feb 2023 at 16:15, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On Sat, Jan 28, 2023 at 01:29:04PM +0100, Ard Biesheuvel wrote:
> > > Create a new status 'dead' which conveys that a subsystem is
> > > unmaintained and scheduled for removal, and developers are free to
> > > behave as if it's already gone. Also, automated build tests should
> > > ignore such subsystems, or at least notify only those who are known to
> > > have an interest in the subsystem in particular.
> > >
> > > Given that Itanium/IA64 has no maintainer, is no longer supported in
> > > QEMU (for boot testing under emulation) and does not seem to have a user
> > > base beyond a couple of machines used by distros to churn out packages,
> > > let's mark it as dead. This shall mean that any treewide changes (such
> > > as changes to the EFI subsystem, which I maintain) can be made even if
> > > they might cause build or boot time regressions on IA64 machines. Also,
> > > mark the port as scheduled for removal after the next LTS release.
> > >
> >
> > Since this just came up, I very much prefer complete removal. I don't
> > see the point of keeping dead code in the tree. That is still hidden
> > maintenance effort.
> >
> 
> Can I take this as an ack on
> 
> https://lore.kernel.org/linux-kernel/20230215100008.2565237-1-ardb@kernel.org/
>

I would not have considered myself important enough to make such a call,
but from a testbed maintainer's perspective it is an enthusiastic yes.

At the same time, again from a testbed maintainer's perspective,
introducing a new "dead" state into the code base deserves a just as
enthusiastic NACK.

Thanks,
Guenter


> ?
> 
> > If this proliferates, we'll end up having to parse the MAINTAINERS file
> > for code marked "Dead" to ensure that we don't accidentally send e-mails
> > to the wrong people, or we risk getting complaints about sending reports
> > for such code. That puts extra burden on maintainers of automated test
> > beds, which I think is not really appropriate. If the code is dead,
> > remove it, period.
> >
> > For my part, I'll drop my test bed support immediately after this patch
> > made it in, following the guidance above.
> >
> 
> Thanks for the insight. I think we should take the immediate removal route.

  reply	other threads:[~2023-02-15 17:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-28 12:29 [RFC PATCH] MAINTAINERS: Mark Itanium/IA64 as 'dead' Ard Biesheuvel
2023-01-28 12:29 ` Ard Biesheuvel
2023-02-15 10:19 ` John Paul Adrian Glaubitz
2023-02-15 10:19   ` John Paul Adrian Glaubitz
2023-02-15 15:15 ` Guenter Roeck
2023-02-15 15:15   ` Guenter Roeck
2023-02-15 15:36   ` Arnd Bergmann
2023-02-15 15:36     ` Arnd Bergmann
2023-02-15 15:40   ` Ard Biesheuvel
2023-02-15 15:40     ` Ard Biesheuvel
2023-02-15 17:08     ` Guenter Roeck [this message]
2023-02-15 17:08       ` Guenter Roeck

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=20230215170815.GA3787950@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=jrtc27@jrtc27.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    /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: link
Be 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.