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

[Daniel Vetter]

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).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch