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=-4.0 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 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 9C2E3C433E0 for ; Tue, 26 Jan 2021 07:31:04 +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 3B59920725 for ; Tue, 26 Jan 2021 07:31:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B59920725 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org 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=shAE72vKdo0U4ualddN5exBCSNCwlFZ5KVe3+yjsxFE=; b=Nk5cBExPkueexYfBEvKgpLif6 F5nKsNIforEnvx9XAyGlvB5K9caawmBLdD0McMRtwQOBmfu8OYXxI9Cj5fSacAupjeUCHcU8VCUWT RWFwXj/jiQeAfASdltn799kn5IuDLduhLrbk6S+WGDClfwObVQGmq7e3HpAtMv8x1WFnn6tY5w/0N SZfg7zGwgWdu2ah78vhWLOJ2W5myHu5o4QEIAkl4beqf4MP5V5Z2qawv0Bwzuwr7u4lu2JO1c0dK6 ZcasYFyeeoorHuz8+DTiLMm2z5lkFGua7Ct84AzvURcJrkZrq2NO9v4Ir9ZMR6vxZHuyyS/y2TPde 1Q1CEcpww==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4In7-0001nI-0Q; Tue, 26 Jan 2021 07:29:33 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4In4-0001mG-2i for linux-arm-kernel@lists.infradead.org; Tue, 26 Jan 2021 07:29:31 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C503222DFB; Tue, 26 Jan 2021 07:29:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1611646168; bh=EeYd7CB89GWAcW8uYhjNeyGSFBIHZRdbLk/gleJ31F0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CNaZz2CRyrqkmqEJ1L1MkcmfJ1EYBiqHIz1t+RsnXvcu8flhZMFUTbYNSpfAd0EQN vC6l8OFAzqdw7q/Yp3BZc0vofaA1B32DcMVvtkoNgXWVbaB+2EnOzBIowUGEbtfyW0 E8r5zyzAOjHkbbqCg+ndL2FzVJpzXyWa5muasrNQ= Date: Tue, 26 Jan 2021 08:29:25 +0100 From: Greg Kroah-Hartman To: Scott Branden Subject: Re: 5.10 LTS Kernel: 2 or 6 years? Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210126_022930_351572_DEC513EA X-CRM114-Status: GOOD ( 19.35 ) 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: BCM Kernel Feedback , LKML , Linux ARM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote: > Hi All, > = > The 5.10 LTS kernel being officially LTS supported for 2 years presents a= problem: > why would anyone select a 5.10 kernel with 2 year LTS when 5.4 kernel has= a 6 year LTS. Because they want to use all of the latest stuff that 5.10 provides them. Don't you want faster and more secure kernels for your devices? > Yet, various unofficial reports indicate it will be supported for 6 years. Rumors are nice, aren't they :) >=A0 And AOSP has already declared the use > of 5.10 kernel in their Android S and T releases. Publically? Where? And is that really the name of the new Android releases, I thought they switched to numbers now (hence the naming of the current android-common kernel branches, marketing is fun...) > Is there some way we could make the LTS support more clear. > A 2 year declaration is not LTS any more. Not true at all, a "normal" stable kernel is dropped after the next release happens, making their lifespan about 4 months long. 2 years is much longer than 4 months, so it still is a "long term supported" kernel in contrast, correct? > If 5.10 is "actually" going to be supported for 6 years it would be quite= valuable to make such a declaration. > https://www.kernel.org/category/releases.html Why? What would that change? Ok, seriously, this happens every year, and every year we go through the same thing, it's not like this is somehow new, right? I want to see companies _using_ the kernel, and most importantly, _updating_ their devices with it, to know if it is worth to keep around for longer than 2 years. I also, hopefully, want to see how those companies will help me out in the testing and maintenance of that kernel version in order to make supporting it for 6 years actually possible. So, are you planning on using 5.10? Will you will be willing to help out in testing the -rc releases I make to let me know if there are any problems, and to help in pointing out and backporting any specific patches that your platforms need for that kernel release? When I get this kind of promises and support from companies, then I am glad to bump up the length of the kernel support from 2 to 6 years, and I mark it on the web site. Traditionally this happens in Febuary/March once I hear from enough companies. Can I count on your support in this endeavor? Also, a meta-comment. Please reconsider using a single kernel version for longer than 2 years on systems that you actively support and maintain. It's generally a bad idea unless you are stuck with millions of out-of-tree code that something like a customer-unfriendly SoC vendor provides. If you are stuck in that type of situation, well they have decided to spend extra money to keep their out-of-tree code alive, so why are they forcing you to also spend extra money and energy? I can go on about this topic at length if you want me to, I have lots of examples of how to, and not to, maintain a kernel for a device for a long period of time... thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel