[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0911030827040.31845@localhost.localdomain>
Date: Tue, 3 Nov 2009 08:37:07 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Marcel Holtmann <marcel@...tmann.org>
cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
David Miller <davem@...emloft.net>, johannes@...solutions.net,
linville@...driver.com, linux-kernel@...r.kernel.org,
linux-wireless@...r.kernel.org
Subject: Re: Please consider reverting
7d930bc33653d5592dc386a76a38f39c2e962344
On Tue, 3 Nov 2009, Linus Torvalds wrote:
>
> And yes, "dealing with it" very much means by-passing maintainers if
> necessary. It can mean sending patches directly to me, but it _also_ means
> asking me to just revert a commit that turns out to be buggy and was
> merged late.
By the way, the "if necessary" part obviously means that I'll be very
happy if it all happens through maintainers. I'm absolutely _not_ arguing
for sending patches directly to me if there is a better way of doing
things.
But I do think that especially as a user who finds a problem, an email
saying "please revert" is a great thing to send to me when you've
identified a problem - especially late in the -rc series.
Of course, you should always Cc: all the people in the patch (author _and_
the sign-off-chain), to give them the opportunity to ask the reporter to
try another patch or to ask me to pull a fix.
Especially as nobody reads email 24/7 and we're all on slightly different
clocks (even within the same timezone we have different schedules: I start
readin mail at 7:30AM, which is probably _not_ what most techies do), so
the optimal situation is that by the time I see the revert request, I
_also_ have another email in my mailbox saying "oh, apply this patch
instead".
So the different schedules _can_ be an advantage, and it's why email is
such a great communication medium for being "immediate, but asynchronous".
We can have overlapping work, and be very efficient when things work well.
The pessimal solution, on the other hand, is to have a very rigid
"channel" so that we end up waiting for several people in a long chain,
all of which are on different schedules, and so each step takes a day or
so to percolate.
Which is what I think happened now.
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