People, these are the early-warning signs of potential burnout. Heed
them and take warning. Linus's stamina has been astonishing, but
it's not limitless. All of us (and yes, that means you too, Linus)
need to cooperate to *reduce* the pressure on the critical man in the
middle, rather than increasing it.
>From the developers, that means a couple of things:
(a) Make your patches small. One functional change per patch. Explain
the change along with the patch. Include explanatory comments in
the patch. Include a description of *how you tested it*. "This
works" is not good enough, not by a long country light-year.
(b) Linus is god until *he* says otherwise. Period. Flaming him doesn't
help, and isn't fair -- and you need to have been the key man in
development of a must-never-fail piece of software before you even
have standing to *think* about doing it.
Now for the tough part. Linus, you are going to hit bad times like
this with increasing frequency, because the present kernel development
process is just not adequate to handle the complexity regime you are
moving into. The basic bazaar strategy still works (the flakiest
2.1.x I've ever seen would be considered production-quality by most OS
vendors) but the ad-hoc way integration is presently handled is
foredoomed to increase frustrations on all sides.
Patches get lost. Patches get dropped. Patches get missed. This is
bad and wasteful in itself, but it has a secondary effect that is
worse -- it degrades the feedback loop that makes the whole process
work. As the average latency of patch integration increases, I
suspect the payoff to developers drops at least quadratically. The
effect of rising uncertainty as to whether good work will make it in
at all is certainly worse than that. Anybody who starts to believe
they're throwing good work down a rathole will be *gone*. If that
happens too many times, we're history.
These risks are bound to get worse over time because both system complexity
and the developer pool are increasing. And the critical man in the
middle -- the "Jesus nut" in our helicopter -- has a stress limit. We're
going to hit that limit someday. Maybe we're pushing it now.
I've been worrying about this problem for months. (I'm our anthropologist,
remember? It's part of my *job* to notice how the social machinery works and
where the failure modes are.) I was reluctant to say anything while it was
still theoretical, but I take the above as a neon-lit warning that it's
damn well not any more.
Linus doing a Stakhanovite "I will work harder" number is not the
answer. His capacity to "work harder" is limited; the scope of the
problem, sadly, is much less so. In fact, taking a few days off is a
very wise thing to do -- and wiser still if it leads to a rethink of some
basic assumptions.
I have some ideas about how to work smarter instead. None of them are
magic and none are very complicated; they're just applications of basic
engineering discipline and a bit of sound resource management. But
before I get into that, I need to ask:
1) Linus, are you willing to have this conversation?
and
2) If so, who else should be involved?
-- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>The following is a Python RSA implementation. According to the US Government posting these four lines makes me an international arms trafficker! Join me in civil disobedience; add these lines of code to your .sig block to help get this stupid and unconstitutional law changed. ============================================================================ from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!= '-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce( lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))
The kind of charity you can force out of people nourishes about as much as the kind of love you can buy --- and spreads even nastier diseases.
- 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/