[lkml]   [2001]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [kbuild-devel] Re: Request for comment -- a better attribution system
    Alan Cox wrote:
    > > Another is to be able to generate reports on exactly how much of the kernel
    > > is in "Maintained" or "Supported" status. I think it would be worth
    > > making this change just so we could know that.
    > There is no correlation between claimed and actual levels of supportedness.
    > There are drivers with no-one supporting them that are common and thus get
    > fixed very rapidly for example.
    > I actually prefer MAINTAINERS because it breaks things down by area and reflects
    > the actual maintainership and areas covered. Something that per file does not

    Question about patches you receive:
    How many patch from Maintainer do you receive?
    How many patch from non-Maintainer do you receive (for maintained code)?
    How many patch from non-Maintainer do you receive (for non maintained
    [I don't need absolute values (but only ratios) nor exact numbers, just
    for make
    me an idea]

    IMHO the problem show in this thead is:
    Where developers should send patches? To Linus/AC or to driver
    ESR proposal enforces this last, but do all mainainers have always time
    for linux
    developement? Should the maintainers be professional? Should Linus/AC
    clean patches from non-maintainers? Do all maintainers read lkml?

    I think the idea of ESR is nice for the normal .c codes. The
    [Cc] and
    Makefile are a very special case, and I think after the inclusion of new
    kbuild in linux kernel, the maintainement of these files will be not a
    issue, so I will not discuss this special case.

    When I find a bug in a file, I check at the top of the file to find who
    is the
    maintainer. Normally I found the address of maintainer, and I will use
    this address. Thus there is already some duplicate address (but the
    in MAINTAINER are sometime old, or missing).
    I see ESR proposal as a clean up/standardization of the head of normal
    This is the case of developer that need to contact a maintainer .

    The top MAINTAINER it is needed for the normal user that find a bug (and
    that don't know the structure of kernel).

    Thus my proposal: We implement the ESR proposal and we create a new
    MAINTAINER file that will list some bugs ML (for each subsystem).
    In this manner the life of not-developer user will be simplified and
    maybe we receive some more bug report.
    Alternativelly we can generate MAINTAINER from ESR's map headers.
    In this case we should include this script in the Linus script to
    automagically create the i386 defconfig.

    BTW ESR's last threads show us some other problem in linux developement
    (or better: the inhomogenity of developement style of some part of
    and we should convince him that the newer subsystem (and arch) should be
    developed as cathedral style (untill stabilization) or we will be
    flooded by big
    kernel patches every few days.


    PS: reading again this email (and doing some additions), I see that we
    standardize maintainers (nor ESR proposal nor in the actual
    ESR proposal cannot give us the right solution. We should live with the
    incomplete MAINTAINERS file and missing maintainers.

    BTW also in Debian we have problems with MIA (and very busy)
    but because we are free project, we should live with that (and no-files
    give us a solution) [in Debian MIA file, here the Date files of ESR

    Thus ESR: If a maintainer did not reply to you (or if you don't find the
    maintainer name), you will be the tmp_maintainer of such files.
    Files could help us, but no so much to solve your (and maybe us future)

    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:27    [W:0.031 / U:5.528 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site