Message-ID: <CA+55aFz8oepgj7W8W=d18qwQt3JUGgv+pCto-_2WS3WJ3ZKqzQ@mail.gmail.com>
Date:	Sun, 15 Apr 2012 10:49:02 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Sergio Correia <lists@...e.net>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk,
	linux-wireless Mailing List <linux-wireless@...r.kernel.org>,
	Sujith Manoharan <c_manoha@....qualcomm.com>,
	"ath9k-devel@...ts.ath9k.org" <ath9k-devel@...ema.h4ckr.net>,
	"John W. Linville" <linville@...driver.com>
Subject: Re: [ 00/78] 3.3.2-stable review

On Sun, Apr 15, 2012 at 10:15 AM, Felipe Contreras
<felipe.contreras@...il.com> wrote:
>
> This is not a reason, this is just stating what happens without
> explaining *why*.
>
> Q: What changes when a tag is made?
> A: A tag is made

I'll make one more try at explaining to you, but then I'll just set my
mail reader to ignore you, because judging by past performance (not
just in this thread) you will just continue to argue.

I'll explain two things. None of those two things are actually about
"tags", although I will start with the issue that is at least
"coincidental" with tags, namely the fundamental nature of reality.

At no point is the "tag" at all important. You are bringing up all
these red herrings, and trying to actively confuse the issue.

The only thing that matters is "it's been made available to others".
That's fundamentally what a release is. If you know physics, think of
a release (and the tag is associated with it) as "collapsing the wave
function". Before that, the outside world doesn't know the exact state
of your tree (they may have good guesses based on the patches they've
seen) - after that, it's "done". You cannot change it. And more
importantly, other people can see the state, and measure it, and
depend on it.

This true regardless of git, btw, but git actually makes that "it's
been available to others" be a real technical distinction, since the
identity of something cannot be changed (so "availability" ends up
meaning "identity" - something is absolutely fixed in stone - you
can't change it, because what you made available is fixed and outside
of your control).

So once some release has been made, you can't change it. If Greg has
made a 3.3.2 release (the tag is not the important part, although the
tag is *coincidental* with the release, of course), then that is what
it is. You cannot change history. You cannot say "oh, we can go back
in time and undo things". There is no change that is a no-op.

THAT is important. And it seems to be something that you don't
understand. The past is immutable. A "tag" has no real other meaning
than as a particular marker of a particular past state. But the tag
itself is not what makes the past immutable. REALITY is what makes the
past immutable.

And reverting a patch DOES NOT CHANGE HISTORY.  It does not magically
go back in time and say "nothing happened". Every time you say that
"reverting a pacth is a no-op", you look more and more stupid, because
you don't seem to understand this fundamental fact.

A revert is nothing but another change. A revert is *exactly* the same
thing as a patch that doesn't revert, but instead fixes. If you cannot
understand that, you're not worth talking to.

And the reason we don't do reverts in stable releases without having
the revert upstream is *EXACTLY* the same reason we don't make other
changes in stable releases without making that change upstream first.

And another really fundamental thing that you don't seem to understand
is that the most important part of "stability" is not actually "bug
free" (which is something we can never attain in any project that is
non-trivial and still evolving), but "reliability". Not even of a
single release, but in *time*. We want to make fundamental and
*reliable* forward progress. And that is why we have the whole "we
don't make changes to the stable tree without having those changes in
upstream first".

And the thing is, it's not just 3.3.3 that follows 3.3.2. It's 3.4.1
too. The reason we have the "no stable fixes before it's been
upstreamed" (and again: a "revert" is *nothing* but another name for a
fix, that gives some additional information about *how* we fixed
something too) is because we want to make nice plodding reliable
forward progress. Mistakes (== bugs) will happen, but the stable rules
are there to make sure that those mistakes get fixed, and don't have
long-term impact. THAT is the "stable" part of the stable series.
Things are monotonic in the big picture, even if we may have some
non-monotonic noise in the details.

If you think that "stable" means "bug free", you are fundamentally
confused about software engineering.

If you think you can go back in time and "undo" things, you are even
more fundamentally confused about reality.

And if you cannot understand what tens of people have tried to explain
to you, you are just f*cking stupid.

                     Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists