* Willy Tarreau <w@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
