> On Aug 10, 2020, at 5:49 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Sat, Aug 08, 2020 at 05:24:53PM +0200, Daniel Vetter wrote: >> 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). > > So for comparison I also looked at mesa3d, which at least compared to > drivers/gpu is very similar: > - 3 months release cycle, 1 month -rc > - very low level C codebase dealing with gpu nonsense > - same Cc: stable process, shamelessly copied from the kernel > - roughly same review process, but recently switched from patch bombs on > m-l to gitlab merge requests (but still pretty similar flow with > detailed per-commit review) > > It has a 0.9% stable ratio over the past year. > > The really big difference is that mesa3d CI is really, really good. Like > we run a ton of unit tests, sw rendering tests and then a bunch of hw > platforms running validation suits. All pre-merge, i.e. before the patches > are even reviewed in detail. And there's a bot used for merging, to make > sure you're patches pass, or they don't go in. > > tldr; roughly the same, except a CI that's a few orders of magnitude > better than what drm/i915 has (especially wrt sporadic issues). Which I > think is still lots better than what any other drm driver has (but it does > help the subsytem overall with catching lots of issues in helpers an core > code). > > So maybe the lower cc: stable is because we catch more crap before it > even lands ... no idea really, and no human can go and quickly review 10k > patches for why there's fewer cc: stable. Or maybe because we have a higher rate of code refactor? :/ But yes, let's work to encourage more people of using Fixes; and cc-stable properly. Luckily we already have some tools in place (dim fixes <has>) that our developers are used to. This will dump the right "Fixes: <hash><commit-subject>" line, and appropriated Ccs, including stable when needed. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
