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/