Messages in this thread | | | Subject | Re: [Wildly off-topic] Re: Linus is on a powertrip.. | Date | Fri, 02 Oct 1998 14:33:18 -0400 | From | David Todd <> |
| |
$.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/
| |