[RFC] MAINTAINERS: Mark Itanium/IA64 as 'dead'

  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.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Jessica Clarke <jrtc27@jrtc27.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-ia64@vger.kernel.org
Link: https://lore.kernel.org/all/CAMj1kXEqbMEcrKYzz2-huLPMnotPoxFY8adyH=Xb4Ex8o98x-w@mail.gmail.com/
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 MAINTAINERS | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
  

Hello Ard!

On Sat, 2023-01-28 at 13:29 +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.
> 
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Jessica Clarke <jrtc27@jrtc27.com>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: linux-ia64@vger.kernel.org
> Link: https://lore.kernel.org/all/CAMj1kXEqbMEcrKYzz2-huLPMnotPoxFY8adyH=Xb4Ex8o98x-w@mail.gmail.com/
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  MAINTAINERS | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5b74014994f5c1cc..5481967c2112e8ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -94,6 +94,14 @@ Descriptions of section entries and preferred order
>  	   Obsolete:	Old code. Something tagged obsolete generally means
>  			it has been replaced by a better system and you
>  			should be using that.
> +	   Dead:	Code has no maintainer and no significant user base,
> +			and is scheduled for removal. Developers are free to
> +			ignore it when it comes to testing bug fixes or other
> +			code changes, and automated build test systems must not
> +			report any detected issues, except possibly to mailing
> +			lists or other recipients that have opted in
> +			specifically to receiving reports about the state of
> +			this code.
>  	W: *Web-page* with status/info
>  	Q: *Patchwork* web based patch tracking system site
>  	B: URI for where to file *bugs*. A web-page with detailed bug
> @@ -9833,7 +9841,7 @@ F:	include/linux/i3c/
>  
>  IA64 (Itanium) PLATFORM
>  L:	linux-ia64@vger.kernel.org
> -S:	Orphan
> +S:	Dead # to be removed after the 2023 LTS release
>  F:	Documentation/ia64/
>  F:	arch/ia64/

Sounds reasonable to me.

Acked-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Adrian
  

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.

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.

Guenter

> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Jessica Clarke <jrtc27@jrtc27.com>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: linux-ia64@vger.kernel.org
> Link: https://lore.kernel.org/all/CAMj1kXEqbMEcrKYzz2-huLPMnotPoxFY8adyH=Xb4Ex8o98x-w@mail.gmail.com/
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  MAINTAINERS | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5b74014994f5c1cc..5481967c2112e8ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -94,6 +94,14 @@ Descriptions of section entries and preferred order
>  	   Obsolete:	Old code. Something tagged obsolete generally means
>  			it has been replaced by a better system and you
>  			should be using that.
> +	   Dead:	Code has no maintainer and no significant user base,
> +			and is scheduled for removal. Developers are free to
> +			ignore it when it comes to testing bug fixes or other
> +			code changes, and automated build test systems must not
> +			report any detected issues, except possibly to mailing
> +			lists or other recipients that have opted in
> +			specifically to receiving reports about the state of
> +			this code.
>  	W: *Web-page* with status/info
>  	Q: *Patchwork* web based patch tracking system site
>  	B: URI for where to file *bugs*. A web-page with detailed bug
> @@ -9833,7 +9841,7 @@ F:	include/linux/i3c/
>  
>  IA64 (Itanium) PLATFORM
>  L:	linux-ia64@vger.kernel.org
> -S:	Orphan
> +S:	Dead # to be removed after the 2023 LTS release
>  F:	Documentation/ia64/
>  F:	arch/ia64/
>  
> -- 
> 2.39.0
>
  

On Wed, Feb 15, 2023, at 16:15, Guenter Roeck 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.
>
> 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.

I agree. While the idea of waiting for an LTS release makes sense
in general (and I did just that for the unused Arm board files), I
don't see how that would help with the timing here: The only remaining
distro with kernel updates is now Debian-ports, and the coming Bookwork
release will apparently use the 6.1-LTS kernel, but as I understand,
the mentioned (late-2023) LTS kernel will not be part either of the
following (mid-2025) Debian release or this one, so keeping it
for a year longer has all the extra cost without any real benefit.

      Arnd
  

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/

?

> 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.
  

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.