Messages in this thread | | | Date | Wed, 30 Sep 1998 22:18:26 -0500 (CDT) | From | "Edward S. Marshall" <> | Subject | Re: 2.1.123 and fbcon.c |
| |
On Wed, 30 Sep 1998, Linus Torvalds wrote: > - I don't mind re-sent patches.
This is one place where a "patch queue" (ala the jitterbug setup) really shines. It doesn't need to be anything fancy, just a way that people can know:
a) He's got my patch (instant gratification for the patch submitter).
b) He's applied/rejected my patch (when the final decision is made, just click it off as "applied" or "rejected", and maybe give a reason if you're feeling particularly offended by the patch ;-).
It's a public queue, so everyone knows what's there, and what's available (ie. one place everyone can go for "quick fixes" for their environment, if they're in a pinch), and it pseudo-organizes things for you. The publicity of it should (hopefully) also cut down on repetition of the same patches over and over when a new kernel is released (how many fbcon.c patches did we see? ;-).
It gives the developers the feedback they desperately need when they want to make sure that your eyes will eventually hit the patch, as opposed to not knowing if they should just resend it, and whether you got it that time, etc, etc, ad infinitum.
It also gives you an easy way of making sure you don't "drop" a patch accidently, thus streamlining things nicely.
Note that I am not saying "use jitterbug". I'm saying, "use a public patch queue", and nothing else should be implied from what I'm suggesting here.
> Essentially, think of it as a communications problem, where the physical > link is reliable, but where you have a many-to-one communication and as a > result the receiver gets overloaded. You want your message to come > through, and you get ACK's but not NACK's. And the latency is on the order > of a few days, but can easily be shorter.
Hmmm...shorten the latency by offloading some of the router CPU's current workload onto other systems (a babysitter, nanny, housekeeper, patch collector, etc)? And, by using the idea above, we introduce NACKs at the application layer, thus working around a deficiency in the protocol. :-)
We won't be happy until you're operating at wire speed, you know. ;-)
-- Edward S. Marshall <emarshal@logic.net> http://www.logic.net/~emarshal/ -o) ------------------------------------------------------ ----- ---- --- -- /\\ Who'd have thought that we'd be freed from the Gates of hell by a penguin? _\_v
- 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/
| |