From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 18AFE875 for ; Mon, 5 May 2014 16:02:24 +0000 (UTC) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 97BC61FC53 for ; Mon, 5 May 2014 16:02:23 +0000 (UTC) Date: Mon, 05 May 2014 18:02:21 +0200 Message-ID: From: Takashi Iwai To: Jan Kara In-Reply-To: <20140505153927.GE23927@quack.suse.cz> References: <53662254.9060100@huawei.com> <5366FBDB.7090705@huawei.com> <20140505134126.GA22287@thunk.org> <20140505153927.GE23927@quack.suse.cz> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Josh Boyer , lizf.kern@gmail.com, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] stable issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , At Mon, 5 May 2014 17:39:28 +0200, Jan Kara wrote: > > On Mon 05-05-14 17:23:18, Takashi Iwai wrote: > > At Mon, 5 May 2014 09:41:26 -0400, > > Theodore Ts'o wrote: > > > The challenge is that companies generally need to be able to make that > > > decision at least 3-6 months ahead of time for planning purposes, and > > > this requires that companies be willing to actually communicate their > > > stablization plans externally ahead of time. Which, unfortuantely, > > > may or may not always be practical. > > > > > > And of course, depending on how many patches get integrated into said > > > "enterprise" kernel, it might end up being very far from the official > > > upstream stable kernel, so it might or might not matter in any case. > > > > Or, other way round: can the upstream LTS kernel be defined earlier? > > Then distros may align to it when it's known beforehand. > > It'd be even helpful for subsystem maintainers to decide whether some > > big infrastructure change should be applied or postponed. > Well, but Greg doesn't want to declare a kernel LTS before it is released > exactly so that people don't cram in lots of imature stuff which needs to > be fixed up later. And I agree with him that this is going to happen if he > would declare LTS kernels in advance. So I don't think this is a good > alternative. I agree with such a possible risk. OTOH, if a big change (or file renames) happens just after LTS kernel, it may make impossible to carry even a small trivial fix back to LTS kernel. So, it can be also a demerit, too. thanks, Takashi