From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15D52C433E0 for ; Thu, 18 Feb 2021 18:36:32 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C094664EB8 for ; Thu, 18 Feb 2021 18:36:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C094664EB8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=1wt.eu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zWQFM7LXiKsQSFzjjINsuUXnVWrGyJKoIEcRyJuiL9E=; b=ttyiTaQ+p5vAvZkAVz3eQaQn5 w1MBCVyaJ3Nlx2kyUpiYqa0gvaadmBHb67fXNXBatFct2MaJrR8TPNCpu/eAdQEJyrOY6hVTylIF1 L2f6icdiPrJFrOvb/x0dzFDBRQnP0Ajs0VgpwDuFTpJMldZFrQPOuBLhAwjr6r/HEpVYVnQqCjDtv MxXSlILjwpdkNitQuZttE661La7i9BJbHWISFxXBChEoz4OGuFeIK7IW4Vz3jHiMw4VqAppPKWfN2 ov4RpwKLAB5nmWSWjM2+xxy1dHIXsQJXV+URi9vx3sedT63IJi8PxptkIVeBdHBvY/ufe7NyKl2FC VPoxzipcw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lCno1-0005Iz-Fe; Thu, 18 Feb 2021 18:13:37 +0000 Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lCnny-0005ID-GY for linux-arm-kernel@lists.infradead.org; Thu, 18 Feb 2021 18:13:35 +0000 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 11IIDU99015369; Thu, 18 Feb 2021 19:13:30 +0100 Date: Thu, 18 Feb 2021 19:13:30 +0100 From: Willy Tarreau To: Florian Fainelli Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Message-ID: <20210218181330.GA15217@1wt.eu> References: <8cf503db-ac4c-a546-13c0-aac6da5c073b@broadcom.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210218_131334_837790_A116E7FD X-CRM114-Status: GOOD ( 17.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg Kroah-Hartman , BCM Kernel Feedback , LKML , Linux ARM , Scott Branden Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Florian! On Thu, Feb 18, 2021 at 09:42:00AM -0800, Florian Fainelli wrote: > > Other difficulty with the LTS version is the frequency it is updated. We would not > > pickup the changes that frequently to test. A quarterly, bi-annually, or when a critical fix > > is identified would be when we update and perform any meaningful testing when in maintainence. > > Well you really have the best of both worlds here, you are not forced to > update your downstream fork of the stable kernel every week, though > bonus points if you do. > > For instance I try to test all the stable release candidates for 4.9, > 5.4 and 5.10, and merge the stable tags every week when they show up. We > do release to our customers every 6 weeks though, so usually they will > jump several stable releases, and they are fine with that. > > Yes it takes time, but I would rather do that than have to continuously > respond to questions about is this CVE fixed in kernel X.Y.Z like it > used to be before we did that. It also helps catch problem faster before > customers do, the usual benefits of continuous integration/delivery. Totally agreed! In our use case at haproxy, it's slightly different but not that much. We're much less sensitive to kernel bugs except for the network parts and any long-term stability issue. However we're extremely sensitive to openssl bugs and haproxy bugs. Thus we use them as triggers to emit a new release and we systematically update the kernel to the latest one. Our local patches usually apply pretty well on top of that. We face maybe 1-3 rejects a year which take half an hour of extra manual work, and roughly one regression every 3 years, essentially caused by one of our local patches applying to the wrong place due to changes and not caught by QA tests before being put online. I think that in ~15 years (we started with 2.4), only a single customer was ever affected by a regression caused by the kernel, it is so low we could almost laugh about it. Quite frankly this is unrivaled, and it illustrates the huge benefit in almost blindly following LTS this way! More quality, less work, and faster response to critical bugs! For sure there's no "kernel hero" in our dev team, but who really wants that anyway ? Cheers, Willy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel