Messages in this thread | | | Date | Tue, 1 May 2018 22:33:25 +0200 | From | Willy Tarreau <> | Subject | Re: bug-introducing patches |
| |
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.
Willy
| |