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 daniel.vetter at ffwll.ch
Sat Aug 8 11:02:34 UTC 2020


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


More information about the dri-devel mailing list