[lkml]   [2002]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A modest proposal -- We need a patch penguin
    On Tue, 2002-01-29 at 09:55, Matthias Andree wrote:
    > On Mon, 28 Jan 2002, Rob Landley wrote:


    > Also, I'm not sure how good Bitkeeper fits here, or whether subversion
    > will help in this way (one might consider feeding suggestions to the
    > subversion team,, if they do atomic
    > commits, one might consider holding them off until blessed by an
    > integrator).

    I'm not sure that a CVS-type solution is going to fix the problem here.
    From what I can see, the problems that people are bringing up are as

    - some patches sent to the list get dropped without comment
    - people are worried about Linus' scalability in handling patches
    - patches time-out quite quickly with the speed of development of
    the kernel, which results in patches not getting applied because
    by the time they get looked they have gone stale
    - people seem to often be unsure about where to send patches
    for unmaintained code, and with no direct maintainer it seems
    that these patches automatically fall outside of Linus'
    trusted kernel people and stand a very small chance of getting

    I must admit that I agree with Linus' position in most places, but the
    result of that is two-fold: a lot of people are left in the dark as to
    the state of their patches (ditched, pending, bad style, etc), and a lot
    of patch work is duplicated as different people fix the same problem
    every couple of months because the fixes are never applied.

    We have two solutions - fix the way that all of this works, or try to
    patch around the resultant problems. It looks like number 1 is not
    going to happen, so why not do something with 2? There has been a lot
    of talk about putting together a system that re-sends patches every
    month or so to lkml, let's write something that does this. We could get
    a number of advantages from this:

    - identification of patches (cleanup, performance improvement, bug
    fix, new functionality, ...)
    - automatic identification of responsible maintainer (direct from
    patch) to email on submission of patch
    - ability to automatically re-diff patch against latest kernel
    versions and get submitter to re-apply if required
    - simple rejection of patches with minimal effort from maintainers
    - easy way for wannabe-patchers to see what patches are already
    pending so they can concentrate on other areas and not duplicate

    Note that this isn't that far from SourceForge, but probably too far to
    make it worthwhile trying to set it up as an SF project. If we do this
    I figure that at worst it allows for auto-resending of patches that have
    slipped through the cracks, and at best it will give people a far more
    suitable mechanism for patch submission and tracking than just email.

    Comments? I'm willing to write it if someone is willing to host it.

    > Matthias Andree

    Jim McDonald -

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

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