On Sat, Aug 8, 2020 at 1:28 PM Greg KH gregkh@linuxfoundation.org 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@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@suse.de wrote:
Hi
Am 07.08.20 um 15:30 schrieb gregkh@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@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.
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