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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxx> wrote: > > > > > > > > Hi > > > > > > > > Am 07.08.20 um 15:30 schrieb gregkh@xxxxxxxxxxxxxxxxxxx: > > > > > 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@xxxxxxxxxxxxxxx> 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
