WTF: patch "[PATCH] drm/mgag200: Remove declaration of mgag200_mmap() from header" was seriously submitted to be applied to the 5.8-stable tree?

Tue Aug 11 14:14:01 UTC 2020

> On Aug 10, 2020, at 5:49 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> On Sat, Aug 08, 2020 at 05:24:53PM +0200, Daniel Vetter wrote:
>> On Sat, Aug 8, 2020 at 1:28 PM Greg KH <gregkh at linuxfoundation.org> wrote:
>>> 
>>> On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote:
>>>> On Sat, Aug 8, 2020 at 12:24 PM Greg KH <gregkh at linuxfoundation.org> wrote:
>>>>> 
>>>>> On Sat, Aug 08, 2020 at 11:13:54AM +0200, Daniel Vetter wrote:
>>>>>> On Fri, Aug 7, 2020 at 3:54 PM Thomas Zimmermann <tzimmermann at suse.de> wrote:
>>>>>>> 
>>>>>>> Hi
>>>>>>> 
>>>>>>> Am 07.08.20 um 15:30 schrieb gregkh at linuxfoundation.org:
>>>>>>>> The patch below was submitted to be applied to the 5.8-stable tree.
>>>>>>>> 
>>>>>>>> I fail to see how this patch meets the stable kernel rules as found at
>>>>>>>> Documentation/process/stable-kernel-rules.rst.
>>>>>>>> 
>>>>>>>> I could be totally wrong, and if so, please respond to
>>>>>>>> <stable at vger.kernel.org> and let me know why this patch should be
>>>>>>>> applied.  Otherwise, it is now dropped from my patch queues, never to be
>>>>>>>> seen again.
>>>>>>> 
>>>>>>> Sorry for the noise. There's no reason this should go into stable.
>>>>>> 
>>>>>> We have a little script in our maintainer toolbox for bugfixes, which
>>>>>> generates the Fixes: line, adds everyone from the original commit to
>>>>>> the cc: list and also adds Cc: stable if that sha1 the patch fixes is
>>>>>> in a release already.
>>>>>> 
>>>>>> I guess we trained people a bit too much on using Fixes: tags like
>>>>>> that with the tooling, since they often do that for checkpatch stuff
>>>>>> and spelling fixes like this here too. I think the autoselect bot also
>>>>>> loves Fixes: tags a bit too much for its own good.
>>>>>> 
>>>>>> Not sure what to do, since telling people to "please sprinkle less
>>>>>> Fixes: tags" doesn't sound great either. I also don't want to tell
>>>>>> people to use the maintainer toolbox less, the autogenerated cc: list
>>>>>> is generally the right thing to do. Maybe best if the stable team
>>>>>> catches the obvious ones before adding them to the stable queue, if
>>>>>> you're ok with that Greg?
>>>>> 
>>>>> As I think this is the first time that I've had this problem for a DRM
>>>>> submission, I don't think it's a big issue yet at all, so whatever you
>>>>> are doing today is fine.
>>>>> 
>>>>> I do think that the number of patches submitted for stable for
>>>>> drm-related issues feels very very low given the rate of change and
>>>>> number of overall patches you all submit to the kernel, so if anything,
>>>>> you all should be increasing the number of times you tag stuff for
>>>>> stable, not reducing it :)
>>>> 
>>>> Ok, sounds like we should encourage people to use the Fixes: tag and
>>>> auto-cc tooling more, not less.
>>>> 
>>>> I also crunched some quick numbers:
>>>> commits with cc: stable in drm/amd: 2.6%
>>>> ... in drm/i915: 2.5%
>>>> ... drm overall: 2.3%
>>>> drivers/ overall: 3.1%
>>>> 
>>>> So from a quick look no big outliers at least, maybe not quite enough
>>>> cc: stable from smaller drivers (i915+amd is about 60% of everything
>>>> in drm). This is for the past year. Compared to drivers/ overall a bit
>>>> lower, but not drastically so. At least if I didn't screw up my
>>>> scripting.
>>> 
>>> Seems about right, so on those averages, you have missed about 40-50
>>> patches that should have been cc:ed stable.
>>> 
>>> However, you are comparing yourself against stuff like drivers/net/
>>> which shouldn't have cc: stable for most stuff (as per the networking
>>> workflow), and other subsystems that seem to never want to cc: stable
>>> for various reasons (offenders not mentioned to be nice...)
>>> 
>>> So let's bump that number up a bit, maybe you are missing 100 patches
>>> this past year that should have been backported?
>>> 
>>> Feels like you all could tag more, even if the number is only 40-50 :)
>>> 
>>> Oh wait, are you sure you don't count the horrid "double commits" where
>>> you backport something from your development branch to your "for linus"
>>> branch, and have cc: stable on both, so that during the -rc1 merge
>>> window I see a ton of commits that are already in the tree?  That would
>>> inflate your numbers a lot more so your real percentages might be a lot
>>> lower...
>>> 
>>> fun with math.
>> 
>> Even drivers/net has like 1.0% cc: stable or so, but yeah maybe a
>> third cc: stable might be missing overall in drm. The math aint more
>> accurate no matter what, but agrees with your "about 100 patches".
>> 
>> And yeah I didn't take out the cherry-picked ones. Trying to grep for
>> those (yay more fun with math) says there's 37 stable commits I
>> double-counted, leaving 1.4% left over for drm/i915. That seems indeed
>> a bit too low :-/
>> 
>> I guess time to add intel maintainers (kinda not my direct business anymore).
> 
> So for comparison I also looked at mesa3d, which at least compared to
> drivers/gpu is very similar:
> - 3 months release cycle, 1 month -rc
> - very low level C codebase dealing with gpu nonsense
> - same Cc: stable process, shamelessly copied from the kernel
> - roughly same review process, but recently switched from patch bombs on
>  m-l to gitlab merge requests (but still pretty similar flow with
>  detailed per-commit review)
> 
> It has a 0.9% stable ratio over the past year.
> 
> The really big difference is that mesa3d CI is really, really good. Like
> we run a ton of unit tests, sw rendering tests and then a bunch of hw
> platforms running validation suits. All pre-merge, i.e. before the patches
> are even reviewed in detail. And there's a bot used for merging, to make
> sure you're patches pass, or they don't go in.
> 
> tldr; roughly the same, except a CI that's a few orders of magnitude
> better than what drm/i915 has (especially wrt sporadic issues). Which I
> think is still lots better than what any other drm driver has (but it does
> help the subsytem overall with catching lots of issues in helpers an core
> code).
> 
> So maybe the lower cc: stable is because we catch more crap before it
> even lands ... no idea really, and no human can go and quickly review 10k
> patches for why there's fewer cc: stable.

Or maybe because we have a higher rate of code refactor? :/

But yes, let's work to encourage more people of using Fixes; and cc-stable
properly. Luckily we already have some tools in place (dim fixes <has>) that
our developers are used to. This will dump the right "Fixes: <hash><commit-subject>"
line, and appropriated Ccs, including stable when needed.

> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch