lkml.org 
[lkml]   [1998]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Wildly off-topic] Re: Linus is on a powertrip..
Date
From
$.02 (long winded diatribe from relative outsider):

I think that what Linus is objecting to is lack of explanation.

Any patch that is submitted should be explainable very briefly, but very, very
completely. This is probably best achieved if the patch fixes or implements
exactly one thing. I would say thing should equal one algorithm, or less.

In a beautiful world, this would probably be achieved in the comments that
would have been added to explain the change in the complete source file. This
mean that the top of the source file would also become a history of the
changes to the file.

I think the ultimate goal here is efficient peer review. Whoever received the
patch should be able to look at the explanation, and look at the entire patch,
and in a very short time, say less than 5 minutes, understand exactly what
should happen, *and what actually happens*.

I think this is what Linus is looking for. I'd dare say the other senior folks
wouldn't mind this either.

Mind you, this is what I think constitutes a *patch*. If you are rewriting an
entire subsystem, it should probably be submitted as an entire subsystem after
substantial testing, and probably not during a codefreeze, even if it is an
experimental, and therefore not required, piece. This just because it slows
down the process, and is a lot of pressure when things are tight.

Receiving a large number of patch all at once, or a single huge patch is
daunting even when you are blessed with copious spare time. But when you are
working a regular job, taking care of family, and under the gun to release a
kernel that senior folks suggested could be out a month ago (admittedly VERY
tentatively), well, you might be more than testy.

I think Linus's explanation of how he wants to work is reasonable. I'd bet he
gets 500 mails a day, many of them patches to this and that. He probably pays
attention to the ones from the senior people first, but I bet he does a
wholesale slash and burn after a certain point, just because it's too much to
deal with at once.

Another reality is important here, one that I am VERY familiar with: even with
procmail, and 3 people watching the mail stream, my group of people miss
email, just because of the volume. This can be bad, because I am a sys-admin,
and people are looking for solutions to big problems. I have had to
consciously tell people "If your problem is still pressing, call me and ask,
as long as you have tried to mail first, and send more mail. It won't offend
me, it's just that you are competing for my attention."

The reason why *I* work this way is that the problems almost always mutate
over time. If someone complains about mail, I want to see if a lot of people
complain. That tells me quicker than anything where the problem is.

With patches coming from myriad sources, it's probably important to not save
old patches because the author might (and often does) notice a bug in a day or
two, and corrects it. If Linus were to save all the patches, and apply them,
and release along the way, he will undoubtedly release versions that the
authors didn't mean to really go out, because there was a mistake in them, and
worse, it's been corrected for 2 weeks.

As to things like jitterbug, I can attest to how annoying it is to be using
multiple interfaces to deal with incoming info. The complaint is that you can
never be even enough in your time budgeting to make people happy, so they'll
try and figure out how to get theirs in faster. Unfortunately, this breaks the
system, because you as the recipient have to spend too much time telling
people how you want to work.

Anyway, back to the shadows.

--
Hacksaw = David Charles Todd
GTEI-BBNT = Hacksaw's Employer
Hacksaw's Opinions != GTEI-BBNT's Opinions
Linux understands you.


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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.043 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site