On Tue 2018-04-17 13:45:59, Sasha Levin wrote: > On Tue, Apr 17, 2018 at 02:24:54PM +0200, Petr Mladek wrote: > >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?). > > I obviously didn't suggest that this patch will go in -stable before > it's upstream. > > I've started doing those because some folks can't be arsed to reply to a > review request for a patch that is months old. I found that if I send > these mails while the discussion is still going on I'd get a much better > response rate from people. I see. It makes sense. > If you think any of these patches should go in stable there were two > ways about it: > > - You end up adding the -stable tag yourself, and it would follow the > usual route where Greg picks it up. > - You reply to that mail, and the patch would wait in a list until my > script notices it made it upstream, at which point it would get > queued for stable. It would be great if the options are described in the mail. I wonder if it would make sense to add also a tag that would say that the commit is not suitable for stable. It might help both sides. The maintainers will be able to share their opinion and eventually reduce mails from autosel. You would get feedback that maintainers considered the patch for stable. It might be even useful for teaching the AI. > >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. > > So yes, I'm aware that the volume of patches is huge, but there's not > much I can do about it because it's just a subset of the kernel's patch > volume and since the kernel gets more and more patches each release, the > volume of stable commits is bound to grow as well. Yes, but the grow in the stable is much faster than the grow in maintain at the moment. It might be fine if it was caused just by engaging subsystems that ignored stable so far. But I am not sure if it is the case. Also I am not sure about your plans. Anyway, I am surprised that the patches might go into stable so easily (no response -> accepted). While it is pretty hard to get through the review process for mainline. Of course, many patches go into mainline without review as well. But the difference is that they are pushed by people that are familiar and responsible for the affected area. I could understand the pain. There are surely people that do not care about stable, because it takes time, it is hard to make decisions, flashbacks to the old code are painful, etc. Well, this is the reason why the maintenance support is and should be limited. Anyway, I think that it cannot be done reasonably without maintainers. You should be careful so that even the currently cooperating maintainers will not start considering autosel mails as a spam. (It is not my case. printk is small thing. But I could imagine that it might stop being bearable in bigger subsystems. As is already the case with xfs.) Best Regards, Petr