Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Handling of embargoed security issues

[Jiri Kosina <jikos@kernel.org>]

On Thu, 6 Sep 2018, Linus Torvalds wrote:

> > I am not completely sure what we could do to improve this, especially with
> > our kernel community hats on -- I am pretty sure a lot is happening on the
> > corporate level between individual "corporate stakeholders".
> 
> One particular pain point this last time around were the stable
> backports, I feel.
> 
> A lot of that was that the actual *fixes* were marked for stable, but
> quite often they were preceded by cleanups and other updates that
> didn't actually fix things directly, and that weren't in themselves
> explicitly marked for stable and didn't have a Fixes: tag, because
> they were prep-work.
> 
> So we had _several_ nasty regressions in stable that never showed up
> in mainline, because there was some non-obvious dependency that didn't
> cause a merge conflict, but did cause a "this commit needed that other
> commit to work right".

I fully agree that this is an issue for stable. On the other hand, I would 
be reasonably sure this has been equally painful issue for stable even 
before this particular disaster (and all the preceeding stable discussions 
on this very ML sort of do support that).

> We should probably at least think about having a way to mark those. 
> Something like a "for-stable-because-of-subsequent-patches" tag?
> 
> Or just more eager use of the table cc? I often feel bad about adding
> "cc: stable" to preparatory patches that don't actually fix the bug,
> but I think it was bad this time around.

Maybe at least partial solution (or first step) to this would be to 
somehow make sure that "these patches form an actual patchset that belongs 
together and is in fact one single thing" information somehow gets 
preserved in maintainer's / your tree.

It's sort-of achievable if everybody (not only the patchset producers, but 
also the consumers) would be very familiar with the idea of strictly topic 
git branches, but that's probably not realistic.

I currently have no good idea how exactly this should be done technically, 
but certainly it's doable and would be of a tremendous help to downstream, 
older-codebase consumers of your tree.

> Of course, I also hope that we're over the worst.

Fully agreed. Also, I hope that world is flat :)

Thanks,

-- 
Jiri Kosina
SUSE Labs