Re: [ 00/78] 3.3.2-stable review

[Ingo Molnar <mingo@kernel.org>]

* Willy Tarreau <w@1wt.eu> 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