lkml.org 
[lkml]   [1998]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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