linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Willy Tarreau <w@1wt.eu>, Byron Stanoszek <gandalf@winds.org>,
	Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	reiserfs-devel@vger.kernel.org
Subject: Re: Is it time to remove reiserfs?
Date: Fri, 25 Feb 2022 19:00:09 -0500	[thread overview]
Message-ID: <YhltiUy/WtA0Dz5g@mit.edu> (raw)
In-Reply-To: <20220225225600.GO3061737@dread.disaster.area>

On Sat, Feb 26, 2022 at 09:56:00AM +1100, Dave Chinner wrote:
> 
> Hence we have to acknowledge that fact that once upstream has
> deprecated a feature, it's up to distros to decide how they want to
> handle long term support for that feature. The upstream LTS kernel
> maintainers are going to have to decide on their own policy, too,
> because we cannot bind upstream maintenance decisions on random
> individual downstream support constraints. Downstream has to choose
> for itself how it handles upstream deprecation notices but, that
> said, upstream developers also need to listen to downstream distro
> support and deprecation requirements...

This is as it should be.  It might not make a difference for reiserfs,
where the development efforts is largely dead already, but once
upstream deprecates a feature, the distributions can no longer rely on
upstream developers to fix a critical stability or security bug in
upstream, so it can be backported into an LTS or stable distro kernel.
They are on their own.

The bug might even be fixed in one enterprise distro's kernel product,
but an isolated patch might not be available; only a megapatch of all
of the distro's changes afgainst an upstrema kernel as a single
un-broken-out-and-GPL-compliant patch.  So a critical bugfix present
in one distro release might not be so easily carried over to another
distro.

So that's an important thing to remember; an LTS kernel as a whole
might be "supported" by a stable kernel team from a backports
perspective for years, but that doesn't mean that a deprecated feature
or subsystem is going to be receiving upstream support, and it's fair
that this be advertised so that users and distributions can make their
own decisions about how long they want to use or support a deprecated
feature or subsystem on a downstream basis.

						- Ted

  reply	other threads:[~2022-02-26  0:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-20 12:13 Is it time to remove reiserfs? Matthew Wilcox
2022-02-20 23:21 ` Edward Shishkin
2022-02-20 23:22   ` [PATCH] reiserfs: get rid of AOP_FLAG_CONT_EXPAND flag Edward Shishkin
2022-02-22 10:27     ` Jan Kara
2022-02-22 13:38       ` Matthew Wilcox
2022-02-23 12:17         ` Jan Kara
2022-02-22 10:04 ` Is it time to remove reiserfs? Jan Kara
2022-02-22 22:16   ` Dave Chinner
2022-02-23 14:48     ` Byron Stanoszek
2022-02-23 15:28       ` Byron Stanoszek
2022-03-17  8:53         ` Thomas Dreibholz
2022-03-17  9:43           ` Jan Kara
2022-02-24  8:46       ` Jan Kara
2022-02-24 14:24         ` Byron Stanoszek
2022-02-24 21:06       ` Matthew Wilcox
2022-02-25 13:10         ` Byron Stanoszek
2022-02-25 13:23           ` Willy Tarreau
2022-02-25 22:56             ` Dave Chinner
2022-02-26  0:00               ` Theodore Ts'o [this message]
2022-04-02 10:57     ` Pavel Machek
2022-04-05 23:04       ` Dave Chinner
2022-04-02 10:54   ` Pavel Machek
2022-04-04  8:55     ` Jan Kara
2022-04-04 10:07       ` Pavel Machek
2022-04-04 10:18         ` Willy Tarreau
2022-04-04 10:58           ` Pavel Machek
2022-04-04 13:05             ` Jan Kara
2022-04-04 12:55           ` Jan Kara
2022-04-04 13:16             ` Willy Tarreau

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=YhltiUy/WtA0Dz5g@mit.edu \
    --to=tytso@mit.edu \
    --cc=david@fromorbit.com \
    --cc=gandalf@winds.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=w@1wt.eu \
    --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 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).