On Tue, May 01, 2018 at 10:33:25PM +0200, Willy Tarreau wrote: >On Tue, May 01, 2018 at 08:00:21PM +0000, Sasha Levin wrote: >> What's worse is that that commit is tagged for stable, which means >> that (given Greg's schedule) it may find it's way to -stable users >> even before some -next users/bots had a chance to test it out. > >But it's a difficult trade-off. I think that -next is mostly used by >developers and that as such the audience remains limited. On the >opposite, -stable is used by many users. So how many days of -next >does it take to get the equivalent coverage of one day of -stable, >I don't know but it's probably a lot. Also server workloads are >almost exclusively on -stable. So a bug affecting only server users >will not benefit from -next exposition. > >In the end it's all about responding to users' expectations to see >the bugs fixed. In -stable we regularly see users asking to backport >certain fixes. Sometimes they have to wait one or two extra versions >before they get their fix, and they are really not happy at all. If >the fix is rushed too fast and doesn't work, they won't be happy >either. Making them happy means backporting the right fix the quickest >possible. Too little test can result in a wrong fix, but too much test >results in a slow backport. > >Again, I really don't find the -stable situation bad nowadays, quite >the opposite. I often suggest to people who don't follow too closely >to stick to latest LTS minus 1 or 2 releases. This way they don't get >the very latest fixes and have a chance that if something breaks very >badly, it gets fixed quickly. It works pretty well apparently. > >I suspect that some of the issues that really need to be improved are >the fixes to recently merged code. That's never easy by definition >because if the code is young, it's not yet very well known even by >its author. > >What *could* possibly be done (though I'm not fond of this) would be >to state a rule that past a certain number of stacked fixes for a >recently merged code, an extra review delay will be enforced on the >subsystem or on patches coming from the submitter. But I really doubt >it would significantly improve the situation.
I think that this discussion has shifted to -stable issues, which is not what I was aiming for. I tried to present a statistic from the recent kernel commits showing that per changed line of code, an -rc commit has more than 3 times the likelyhood to introduce a bug rather than a merge window one. Is this something the community sees as an issue, or do we expect a significantly higher odds of introducing bugs in -rc commits? Feed free to ignore any proposals I've made. If you see this as an issue, what could we do to address it? Let's leave -stable out of this for now.
