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

[Greg KH]

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.

greg k-h