Received: by 10.192.165.148 with SMTP id m20csp5357024imm; Tue, 1 May 2018 13:34:27 -0700 (PDT) X-Google-Smtp-Source: AB8JxZopjZvZGc5X+3ZcSQSCkscbySk55EfBLKLSz7VsIi1SqqE+FMZfhvCmxiY0/cbvnOOahM2F X-Received: by 2002:a17:902:102:: with SMTP id 2-v6mr17712596plb.48.1525206867414; Tue, 01 May 2018 13:34:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525206867; cv=none; d=google.com; s=arc-20160816; b=kJLdVTwtQuz97MrtS1c2GMFE5jcc0/nkFBu/YQdHwpFpugDJphEs/72OrYd552xWGa vvGhriofGS2WXAaOnqfEhO8RbS5V/vUOF91FSgXZFhC6LATwn3plDqtZmnwT0CR45YZu 9AIfKexfJP6X7V/zEPgXvFKwTtHpbRnYMdwXy6FaIVGuyipazLYOkn94k2Q90InWQPIq js1kQzeNF/HQ1GPnjJDxPcoqRbZpgMdCXkeMV+l7nQH2J4kb2PFoXSLbLWY4XOaoVYXs XV+Mmm2dranr41A9JZojcXdNwZUW00LsetPZSFmxfz2lg3JhCSa/UUk9a4js5L98g4/c T6wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=VqTqtZbfADKH9K09A6Wdke+i+ni1r1usaI79pKXsDvk=; b=O8uUMO3UhLuYWuogBeMaW69EwyZBF268L3PLVIxjRDuuNycF/ZNNXhSLfSfirQq5lo iGmAqCNqHEh8Oqrr9EHR+zEGOS690a+IgjHtB1/ofM2b5KEaGq99xORRudaHI+5hx/7g OVB8wJWqCjs6vu6VPCJUllvoisbS4F6WPEr4FfxLTA5h/K3Fd8hr27e8eeacpdbndNru 5xIe9XUPDn8ypDYa7lpBWJUy2ATv1qFtrjnEen2mWb0StK+ub7ngtzFgMrP7pf71vsqA sXFIr6dPggjWRqx0ZLKZlk4OOrk/3aLsU5VKaCRMQ7i7AvssysDXPuiA4pOjtO68DGxF DAjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z18si1490830pfd.357.2018.05.01.13.33.56; Tue, 01 May 2018 13:34:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750945AbeEAUdl (ORCPT + 99 others); Tue, 1 May 2018 16:33:41 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:45144 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750743AbeEAUdk (ORCPT ); Tue, 1 May 2018 16:33:40 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w41KXPEn011635; Tue, 1 May 2018 22:33:25 +0200 Date: Tue, 1 May 2018 22:33:25 +0200 From: Willy Tarreau To: Sasha Levin Cc: "Theodore Y. Ts'o" , "ksummit-discuss@lists.linuxfoundation.org" , Greg KH , "julia.lawall@lip6.fr" , "linux-kernel@vger.kernel.org" Subject: Re: bug-introducing patches Message-ID: <20180501203325.GB11618@1wt.eu> References: <20180501163818.GD1468@sasha-vm> <20180501194450.GD10479@thunk.org> <20180501200019.GA7397@sasha-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180501200019.GA7397@sasha-vm> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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