lkml.org 
[lkml]   [1998]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Automating 2.3 patches
    On Thu, 15 Oct 1998 teamwork@freemail.c3.hu wrote:

    > Andreas and Rik are both involved in ways to curb the OOM problem
    > for Linux. Andreas' way is to have the OOM protection be included
    > in the kernel, but Rik's approach is to get the OOM protection as a
    > standalone daemon. Right now, Linus has yet to include either Rik's
    > or Andreas' OOM protection approach in his official tree.

    This was not such a great example, for the following reasons:
    - my patch includes the OOM protection in the kernel too
    (well, that doesn't change the example, but I'll mention it)
    - Andrea's patch and my patch are good complements to eachother,
    there's no reason to throw away any of our efforts

    The last reason is also the reason why Andrea and I keep
    'communicating' the way we are. If it wasn't the case,
    we'd probably both go for a cool-down-a-moment period :)

    > Patch submitters no longer have to wait for Linus
    > to approve of their approach, and they no longer
    > have to go to 20 different places to submit their
    > patches.

    This is a nice thing to do for 'homeless' patch writers.

    The MM patches can be accessed through the Linux-MM homepage
    though (not sure if I linked Andrea's patch repository, I'll
    check that when my exam is over)...

    Having dedicated sites for each subsystem would, IMHO, be better
    than a central site, since specialised sites can go much more
    in-depth and provide other stuff as well (documentation, mailing
    list archives, TODO lists and technical musings).

    > All they have to do is to write up a brief
    > description of their patch, submit it to the website
    > (in appropriate category, of course.)

    It's still a nice idea, though. Maybe we should do
    something like this...

    > * How such website benefits the ordinary Linux users:
    >
    > Let's assume there is a Linux user Joe Blow, who
    > doesn't know how to write a SCSI driver.

    Yeah, that sucks {;-)

    [SNIP driver available, but not locatable]

    > Now what does Joe Blow do?
    > Does user Joe Blow have to search the entire Net
    > for such a driver?
    > Or does he make multiple annoying requests on as many
    > mailing-lists (and/or newsgroups) he can find, making
    > him an instant flaming target?

    OK, you convinced us that a more-or-less central site
    for patches is needed.

    I still think that a human-managed site for each individual
    subsystem is better, but that's probably just a matter of
    opinion...

    On a side note, if anybody knows of a subsystem site that's
    not already listed on the "kernel links" section of my
    Linux-MM site, please let me know. I will add the links
    immediately.

    It will also be a good idea to report yourself for
    http://webwatcher.org/, since that site currenly only
    lists _one_ Linux kernel subsystem site (Linux-MM).

    > If a central Linux patch clearinghouse website is
    > available, Joe Blow could have point his browser to it,
    > and go down to the SCSI directory and search for the
    > required driver.

    s/SCSI directory/SCSI subsystem site/
    s/driver/driver, documentation and generally patronizing warnings/

    > * How such website brings together Linux hackers and users:
    >
    > And because the website is the central clearinghouse
    > for all Linux patches, most Linux users with with SCSI
    > expertise will visit the SCSI section of the website.

    True, but a 'central' site will probably make for a
    less attached SCSI community as well. Maybe we'll want
    a central site, but with the possibility of each subsystem
    maintaining it's own site instead...

    > Hence the possibility of someone code up a working XYZ
    > SCSI driver is very great.

    Yup, we really should do something like this.

    > * How such website benefits mailing-lists like L-K:
    > * How such website benefits maintainers:

    Anybody? What we need now are volunteers...

    > And I did propose a "Good/Bad" type of voting feature for
    > the website. Good patches will get mostly "Good" votes,
    > while broken patches will get mostly "Bad" votes.

    This could be a bad idea. Version 2 of a patch might
    be very very different from version 1, but it could
    still have the bad name.

    It would be best if the programmer of the patch gets
    all the bug-reports in his/her mailbox and puts up
    a little message to the community if he/she feels like
    it.

    Just having anybody vote on a patch will result in
    a fast and brutal dismissal of ideas that don't look
    so great at first sight. I can remember that the
    OOM killer provoked a large flamefest ("What, I don't
    want the kernel killing my processes") when first
    proposed.

    A second - very sneaky - proposal led to a better
    acceptance ("I don't want X to die unexpectedly"
    "Well, maybe we should put some code in the kernel
    to not kill random processes"), but still there
    are people who just glance over the messages and
    then come out with a strong (unfounded) opinion...

    I don't want folks like that to vote over my
    patches. Often the kernel works very counterintuitive,
    so casual surfers really can't make judgements about
    patches.

    > Coupled with the availability of simple description
    > spaces for the voters to voice their opinions,
    > maintainers for specific peripheral (platform) can base
    > their decision on which one to include, which one to
    > reject on the comments (and the vote-counts) of the
    > various patches.

    Maintainers should (and probably will) base their decisions
    on the quality of the code, and not because of democratic
    stuff going on. Linux is not a democracy, it is a meritocracy
    with a benevolent dictator taking the final decisions.

    > With this website, the existing maintainers will keep their source
    > tree, but they get to have much more participatory peer-reviews on
    > the patches they put on their trees.

    This will be another advantage. Making it easy for people to test
    patches, will most likely increase development speed, thereby
    making the whole process more rewarding for the programmers.

    > and when they [Linus and Alan] need to find things that are
    > reliable, they can base their choice on the "recommendations" from
    > the people who actually _used_ the patches.

    Having all the reactions to one patch in the same place
    is a large advantage indeed. This point could make the
    job of Linus and Alan a little easier -- if they want it
    this way...

    > I hope a enterprising Linux user may start such a website soon. The
    > current patch submission process is too cumbersome, and the gap
    > between the patch authors and patch users are too wide for the
    > average Linux users.

    So do I. Most Linux subsystems still lack all clarity
    and there's no way for someone with little time to
    figure out what's going on inside the devel group.

    Rik.
    +-------------------------------------------------------------------+
    | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
    | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
    +-------------------------------------------------------------------+


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

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