From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-we0-f174.google.com ([74.125.82.174]:34356 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750823Ab2DPGiw (ORCPT ); Mon, 16 Apr 2012 02:38:52 -0400 Date: Mon, 16 Apr 2012 08:38:40 +0200 From: Ingo Molnar To: Willy Tarreau Cc: Felipe Contreras , Linus Torvalds , Greg KH , Sergio Correia , linux-kernel@vger.kernel.org, stable@vger.kernel.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, linux-wireless Mailing List , Sujith Manoharan , "ath9k-devel@lists.ath9k.org" , "John W. Linville" Subject: Re: [ 00/78] 3.3.2-stable review Message-ID: <20120416063838.GA23628@gmail.com> (sfid-20120416_083940_432516_AE334C3E) References: <20120414104733.GA4871@gmail.com> <20120415065124.GC29563@gmail.com> <20120416053911.GL27728@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20120416053911.GL27728@1wt.eu> Sender: linux-wireless-owner@vger.kernel.org List-ID: * Willy Tarreau wrote: > It's not the user's visibility, it's published code. Once code > is published, you cannot magically fix it without emitting a > new patch for this code and announcing so that users apply it. > These patches are called stable releases. Users want a good > reason to apply these patches, rebuild and reboot, and that's > one reason we absolutely want to have the commit descriptions > from upstream which detail the exact reason for the patch > (even if it's a revert). Let me also outline why reverts are important and why they are not just 'a patch removed'. A revert carries valuable information: we revert a broken commit not just with the terse description that it's broken, but with an exact description about *why* it's broken and how that breakage relates to the original patch. In the limited 'patch space' nothing happened: a patch was done, then undone. In the Git 'commit space' the picture is very different: we have a commit that does a change with a justification and we have *another* commit that undoes the code modification with *another* justification. We got richer by two justifications and the kernel got *more stable* in the process even though no actual code changed: - We very likely won't repeat this mistake again, it's documented for eternity to any developer touching this code in the future. See Linus's arguments about 'monotonic progress'. Git hashes force the causality of the real physical world on us, which is *especially* useful when we make mistakes and would like to use a digital time machine that whitewashes our shades of grey history. - In practice developers tend to be more careful with code that sees an above average ration of reverts. It's a red flag - it shows that the code, the hardware or the development process maintaining that code is somehow non-obvious and fragile for one reason or another. - In most cases a change+revert also spurs further development: the original justification is likely valid and people want to achieve that advantage but via some other, non-broken means. In that sense the revert is a persistent TODO entry as well, for developers. If the bug was just a report somewhere in a mailing list archive on the web then it would bitrot quickly and people would not have a way to find it and react to it in an organized way. By making it a Git commit; the change, the fix and all the justifications around it become a permanent part of Linux - which is more than just 15 million lines of code ... Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Date: Mon, 16 Apr 2012 08:38:40 +0200 Subject: [ath9k-devel] [ 00/78] 3.3.2-stable review In-Reply-To: <20120416053911.GL27728@1wt.eu> References: <20120414104733.GA4871@gmail.com> <20120415065124.GC29563@gmail.com> <20120416053911.GL27728@1wt.eu> Message-ID: <20120416063838.GA23628@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org * Willy Tarreau wrote: > It's not the user's visibility, it's published code. Once code > is published, you cannot magically fix it without emitting a > new patch for this code and announcing so that users apply it. > These patches are called stable releases. Users want a good > reason to apply these patches, rebuild and reboot, and that's > one reason we absolutely want to have the commit descriptions > from upstream which detail the exact reason for the patch > (even if it's a revert). Let me also outline why reverts are important and why they are not just 'a patch removed'. A revert carries valuable information: we revert a broken commit not just with the terse description that it's broken, but with an exact description about *why* it's broken and how that breakage relates to the original patch. In the limited 'patch space' nothing happened: a patch was done, then undone. In the Git 'commit space' the picture is very different: we have a commit that does a change with a justification and we have *another* commit that undoes the code modification with *another* justification. We got richer by two justifications and the kernel got *more stable* in the process even though no actual code changed: - We very likely won't repeat this mistake again, it's documented for eternity to any developer touching this code in the future. See Linus's arguments about 'monotonic progress'. Git hashes force the causality of the real physical world on us, which is *especially* useful when we make mistakes and would like to use a digital time machine that whitewashes our shades of grey history. - In practice developers tend to be more careful with code that sees an above average ration of reverts. It's a red flag - it shows that the code, the hardware or the development process maintaining that code is somehow non-obvious and fragile for one reason or another. - In most cases a change+revert also spurs further development: the original justification is likely valid and people want to achieve that advantage but via some other, non-broken means. In that sense the revert is a persistent TODO entry as well, for developers. If the bug was just a report somewhere in a mailing list archive on the web then it would bitrot quickly and people would not have a way to find it and react to it in an organized way. By making it a Git commit; the change, the fix and all the justifications around it become a permanent part of Linux - which is more than just 15 million lines of code ... Thanks, Ingo