[Ksummit-discuss] [CORE TOPIC] stable workflow

[Greg KH]

On Wed, Aug 03, 2016 at 09:23:32PM -0400, Steven Rostedt wrote:
> On Wed, 03 Aug 2016 10:04:55 -0400
> James Bottomley <James.Bottomley at HansenPartnership.com> wrote:
> 
> 
> > OK, so how about you only apply stable patches with a cc stable and a
> > fixes tag?
> 
> While reading this thread, I thought about replying and suggesting
> exactly this. But you did it before I could.
> 
> I try to make it a habit to find the commit that a fix is for, and add
> that as a Fixes tag and even add a # v<stable-version>+ to the Cc tag.
> 
> Maybe we ask that all cc stable commits have this, otherwise it should
> only be applied to the previous stable and nothing earlier.

No, again, that would put more burden on the maintainer and developer
than I want to "enforce".  I don't even want to do that extra work for
the trees I maintain, I just couldn't scale that way.

> IIUC, Greg et.al. will apply a stable tagged commit to all previous
> stable trees as long as they apply cleaning. Greg, is that correct?
> Perhaps we shouldn't apply them if they don't have a fixes tag or a
> label that states what versions they are for.

I apply them to older kernels based on my best judgement.  That includes
reading the patch, seeing how "cleanly" they apply, and judging the
severity of the patch.  I only notify developers if their patch doesn't
apply to an older kernel tree IF they have marked it as explicitly being
needed for an older kernel tree.

Now I greatly appreciate the use of fixes: and other hints to show how
old a patch should be backported to, don't get me wrong.  But I'm not
going to require that it be present in order to have a patch backported,
again, too much work for maintainers.

It's up to anyone who wants to maintain a "longterm" stable tree to do
this extra work on their own.  It's not easy, and it is work, but that's
just part of the job.  We can't force maintainers to care about older
kernel versions if they don't want to, as maintainers are our most
limited resource right now.

Remember, we _still_ have whole subsystems that never mark anything for
stable, let's focus on them please, that's the biggest issue for stable
trees that I can see right now.

thanks,

greg k-h