Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp734858pxm; Fri, 25 Feb 2022 18:42:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJxMlMvOtPgJz7e0WABBUXftRTb5B649sthfv3pRIrCPE/tGBfBQvJ1vJYPfCy/EZ/sT5P1V X-Received: by 2002:a63:2fc1:0:b0:374:9f30:9559 with SMTP id v184-20020a632fc1000000b003749f309559mr8542414pgv.278.1645843341446; Fri, 25 Feb 2022 18:42:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645843341; cv=none; d=google.com; s=arc-20160816; b=qK2g0ePjV/w96SOtdSi7FIo5WEAG2QXjtTCECfMEdw1CMByfUy6HxYxXsKsX5P2B9h leIUtsguugBJhBnaLwgs58QulLonGBvQyncsSKKRHbiIgedd6sibZj8vjZWuLXW9Uzin /wbuQDOvXPE6mnnDWUZuVQ5M2RdzwXUZZEM/RkoxVIBkw9656HsszccfyrkXBjkyW5N0 +T64CrJgQLNnDIJTTpB3uFufTBjRL0wNvkL05vDUbeH7JQFezKgID42xS8a8ir4/w/sb 5zlkVJ63aVE+X1Gpo17CHYmJc5zXcQy4d7MUteb5P50F+i26MpoU/2KLWbDFyQNfMmpo Xdjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=twgZbwbE5364pkaFNhfCIqb1j/DH5EHQ2s0dEw/7UcM=; b=qUclWccUeBKNmQcIx4j3ub/LtX7FNO9iCCUTEFyXvQK/jQeZaxlQb0/PBrIb9CFrp0 d9RyDiAKaH0OMWjN5PYm0rSgQFerUtVxySwOOQ1w+KSJ1JixJYVUSlPo1N3k5t0CgUYv PbQmp/fTaoM20muvMBEEHP0GzVrjj5+ecZRqAUg0l7SAOPstqtDDEn6sw4KRHqkEN17Y dPl4QYidMSp7EpVwj6WBie28Wcby1ubGgN6klMsxGAh1OEVSon+bqkirRQC2iuo/EvWI PWQKhR/HEIY0NxqhFGHYZTUYjiJOLAreq1xPvWSYOVzQuY9WZdrCjQ0cdDfsl/Ne2xFW bXLg== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h3-20020a056a00230300b004f0f256db2esi3879470pfh.14.2022.02.25.18.42.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 18:42:21 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2FC69240D23; Fri, 25 Feb 2022 18:06:32 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239838AbiBZABX (ORCPT + 99 others); Fri, 25 Feb 2022 19:01:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230035AbiBZABW (ORCPT ); Fri, 25 Feb 2022 19:01:22 -0500 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB8BD1FED87; Fri, 25 Feb 2022 16:00:48 -0800 (PST) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 21Q0093w027074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Feb 2022 19:00:10 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 9E38515C0038; Fri, 25 Feb 2022 19:00:09 -0500 (EST) Date: Fri, 25 Feb 2022 19:00:09 -0500 From: "Theodore Ts'o" To: Dave Chinner Cc: Willy Tarreau , Byron Stanoszek , Matthew Wilcox , Jan Kara , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, reiserfs-devel@vger.kernel.org Subject: Re: Is it time to remove reiserfs? Message-ID: References: <20220222100408.cyrdjsv5eun5pzij@quack3.lan> <20220222221614.GC3061737@dread.disaster.area> <3ce45c23-2721-af6e-6cd7-648dc399597@winds.org> <257dc4a9-dfa0-327e-f05a-71c0d9742e98@winds.org> <20220225132300.GC18720@1wt.eu> <20220225225600.GO3061737@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220225225600.GO3061737@dread.disaster.area> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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