Re: [Ksummit-discuss] [CORE TOPIC] stable issues

[Takashi Iwai <tiwai@suse.de>]

At Mon, 5 May 2014 12:07:52 -0400,
Jason Cooper wrote:
> 
> On Mon, May 05, 2014 at 06:02:21PM +0200, Takashi Iwai wrote:
> > 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.
> 
> Do you have an example of this?  git is pretty darn good about tracking
> renames.  If you've had a patch you couldn't backport, I'd like to see
> what caused the failure.

An example I hit in past was mostly when a code was split.  Then it
can't be backported without the manual fix.  The pure file rename
might work, but often more incompatible changes follow after that
(which is the purpose of cleanup by renames, after all).

> In the worst case scenario, the maintainer of the code (or anyone
> intimately familiar with it) should be able to hand-apply it.  But to
> me, that would highlight a shortcoming of the system.

Sure, a handmade backport is always possible.  But this means that it
would result in more burden to maintainers, just because they didn't
do it in the right time.


thanks,

Takashi