On Tue 2018-04-17 12:46:37, Greg KH wrote: > Oh, I know why, suddenly subsystems that never were taking the time to > mark patches for stable are getting patches backported and are getting > nervous. Yes, I am getting nervous because of this. The number of printk fixes nominated for stable is increasing exponentially (just my feeling) during last few months. The problem is that I want to be responsible and think about possible regressions. Sometimes it requires checking the state of the particular kernel release. The older code base the more complicated the decision is. You might argue that backporting the fixes helps to get the same code in all supported code bases. But it is not true. It never will be the same. Anyway, in the past the "automatically" nominated printk fixes were trivial. They did not cause harm. But they also were not worth it, IMHO. They fixed corner cases that were there for ages. Most of these fixes were found by code review when working on a feature. They were not backed by bug reports. Last week, autosel nominated pretty non-trivial patch (started this thread). It partly solved a problem we tried to fix last few years. On one side, this was an annoying problem that motivated several people spend a lot of time on it. This might be a motivation for a backport. On the other hand, it took many years to come somewhere. The main problem was the fear of regressions. We fixed/improved many things in the mean time. It shows that the problem really is not trivial. The same is true for the fix. We did our best to avoid regressions. But it does not mean that there are none. Also it does not mean that it will really give better results in all situations. I really do not see a reason to hurry and backport this to the older kernel releases. It means to spread the fix but also eventual problems. It is easy to miss a dependant patch. The less trivial fix, the more possible problems are there. Back to the trend. Last week I got autosel mails even for patches that were still being discussed, had issues, and were far from upstream: https://lkml.kernel.org/r/DM5PR2101MB1032AB19B489D46B717B50D4FBBB0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx https://lkml.kernel.org/r/DM5PR2101MB10327FA0A7E0D2C901E33B79FBBB0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx It might be a good idea if the mail asked to add Fixes: tag or stable mailing list. But the mail suggested to add the unfinished patch into stable branch directly (even before upstreaming?). Now, there are only hand full of printk patches in each release, so it is still doable. I just do not understand how other maintainers, from much more busy subsystems, could cope with this trend. By other words. If you want to automatize patch nomination, you might need to automatize also patch review. Or you need to keep the patch rate low. This might mean to nominate only important and rather trivial fixes. Best Regards, Petr
