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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.024 / U:0.384 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site