On Sat, Aug 8, 2020 at 1:28 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
