Date:	Wed, 30 Sep 1998 10:34:54 -0700 (PDT)
From:	Linus Torvalds <torvalds@transmeta.com>
To:	Rogier Wolff <R.E.Wolff@BitWizard.nl>
Subject: Re: 2.1.123 and fbcon.c



On Wed, 30 Sep 1998, Rogier Wolff wrote:
> Linus Torvalds wrote:
>
> > Note that if some person cannot be bothered to re-submit, I don't WANT the
> > patch. Anybody who is not willing to take that much care of his patches
> > that he can't maintain it while I haven't accepted it, I don't want to
> > accept patches from anyway. 
> 
> Linus, the problem is that when I submit a patch, I don't want to
> unneccesarily overload you by resubmitting on too short a notice. 

If this is the problem, we can easily rectify that by just setting up a
few reasonably simple guidelines. I'm really not hard to work with, it's
just that I get overloaded, and when I have more important things (be they
Linux-related or not), I start dropping. 

Think of me as a slow network card that drops packets when overloaded, and
use a TCP-like congestion avoidance technique ;) 

The guidelines are fairly simple:

 - I don't mind re-sent patches. At worst, I can just drop it again, and
   on the whole that's simply not a problem. I obviously don't want to be
   patch-flooded, and for practical reasons it's just silly to re-send the
   same patch two days in a row, but sending a patch a week later is not a
   problem for me, even if the first one is still on my mind. 

 - At the same time, I don't think other developers should need to worry
   overmuch. If you have a patch that you think should go in, but is not
   something you have hanging over your head all the time, I don't mind it
   in the least if you decide that it can wait more than a week. So you
   should _not_ have the feeling that you have to check my patches every
   week to see whether it made it in this time. 

 - It's ok even to resend a patch that I already applied, as long as it's
   _exactly_ the same patch as you sent last time. I keep track of what I
   apply, believe it or not, and it's fairly low-overhead for me to go
   "Oh, I've seen this patch before, drop it". It's only if your new patch
   conflicts with an older one that there can be problems (I might decide
   to drop it exactly because I had already seen it before, and then the
   changes would be lost)

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. 

		Linus


-
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/