ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Arnd Bergmann <arnd@arndb.de>,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence
Date: Sun, 16 Aug 2020 22:53:29 +1000	[thread overview]
Message-ID: <874kp2ah12.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <CAK8P3a2PK_bC5=3wcWm43=y5xk-Dq5-fGPExJMnOrNfGfB1m1A@mail.gmail.com>

Arnd Bergmann <arnd@arndb.de> writes:
> I have submitted the below as a topic for the linux/arch/* MC that Mike
> and I run, but I suppose it also makes sense to discuss it on the
> ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
> even if we don't discuss it at the main ksummit track.
>
>      Arnd
>
> 8<---
...
>
> I propose adding a Documentation file that keeps track of any notable
> kernel feature that could be classified as "obsolete", and listing
> e.g. following properties:
>
> * Kconfig symbol controlling the feature
>
> * How long we expect to keep it as a minimum
>
> * Known use cases, or other reasons this needs to stay
>
> * Latest kernel in which it was known to have worked
>
> * Contact information for known users (mailing list, personal email)
>
> * Other features that may depend on this
>
> * Possible benefits of eventually removing it
>
> With that information, my hope is that it becomes easier to plan when
> some code can be removed after the last users have stopped upgrading
> their kernels, while also preventing code from being removed that is
> actually still in active use.
>
> In the discussion at the linux/arch/* MC, I would hope to answer these
> questions:
>
> * Do other developers find this useful to have?

Yes!

> * Where should the information be kept (Documentation/*, Kconfig,
> MAINTAINERS, wiki.kernel.org, ...)

Documentation/ seems like the obvious place. Possibly also somewhere on
wiki.kernel.org or elsewhere so that people can contribute information
without having to submit a formal patch.

> * Which information should be part of an entry?

Your list above is pretty good.

For features that relate to specific hardware I think it would be useful
to have some more information.

For example when the hardware was last manufactured, who made it, how
could it be purchased when it was available (eg. was it for sale to the
public or in limited quantities or only to certain people or internal to
a particular company).


> * What granularity should this be applied to -- only high-level features
> like CPU architectures and subsystems, or individual drivers and machines?

I think it can make sense at many levels. It probably just depends on
how much effort folks want to go to in order to track down the
information.

Looking at powerpc it would be useful to have that sort of info for
individual boards, as well as each platform, CPU families and specific
drivers.

cheers
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

      parent reply	other threads:[~2020-08-16 12:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31 15:00 Arnd Bergmann
2020-07-31 21:27 ` josh
2020-07-31 21:57   ` Bird, Tim
2020-07-31 22:47     ` josh
2020-08-05 17:26 ` Pavel Machek
2020-08-05 18:50   ` Geert Uytterhoeven
2020-08-05 19:30     ` Pavel Machek
2020-08-10 19:39       ` Olof Johansson
2020-08-16 12:53 ` Michael Ellerman [this message]

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=874kp2ah12.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=arnd@arndb.de \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rppt@linux.ibm.com \
    --subject='Re: [Ksummit-discuss] [TECH TOPIC] Planning code obsolescence' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).