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
