lkml.org 
[lkml]   [1999]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ OFFTOPIC ] Re: The Linux Kernel Project Management System (INITIAL PROPOSAL)
    Could you please come back to a) technical and b) Linux dependent
    discussion? The flame war you're doing here (esp. Larry McVoy) is
    definitely non-productive. Remember: we talk about Source Management for
    Linux and not for a big archive or commercials.

    Jordan Mendelson wrote:

    > If a solution to kernel source management is to be found, it must
    > incorporate
    > all the same features that the current system allows. There are four
    > distinct
    > pieces to the kernel development process:
    >
    > § Source Repository
    > § Bug Reporting & Tracking System
    > § Patch Submission & Peer Review System
    > § API Documentation Submission

    To add some other points:
    *the traditional solution for bugfixes in OpenSource is "take the newest
    version from the stable tree" - so the backup of older versions is
    definitely _no_ problem. Only few scientists will be interested in
    five-year-old Linux versions.
    *Especially the Linux sources are mirrored on hundreds of servers all over
    the world, so if one server eats the files on it we can restore by
    catching any copy out there. If the main server (at Linus' side) crashes
    he still can catch a copy from somewhere and then ask the developers to
    resend their patches. Crashes are unlikely (under a stable Linux server)
    so this case will be very rare and the manual solution is acceptable.
    *The mirror servers have quite large disks (remember: diskspace is cheap
    these days) - the size of the local image is no problem.
    *Many developers have only slow and expensive Modem-lines to transfer and
    update theyr database. The questions are:
    - how much does the system compress my data (or even: may I plugin newer
    and better compression algorithms)
    - how much overhead does the transfer need (counted in bytes transferred
    through the net, not bytes stored on local/remote harddisk; call it
    compression of metadata)
    - may I chose in which changes I am interested and which not to transfer
    (eg. Alan may decide to transfer everything from Linus and some other
    trusted users but he might want to review a short description of the
    patch for those patches from everyone else)
    *OpenSource is less hierarchical than commercial development - so it is
    necessary to get good (easy to understand) views of the various source
    trees and patches. And we would need flexible tools to (un)merge and
    change patches and to move whole sets of patches from one tree to
    another.
    *Many developers will decide to hold their own local tree of patchsets. So
    we need a tool with a kind of access rights and distributed
    administration. The base server for the linus-tree will be another one
    than the base server for ac or davem. And the base servers definitely do
    not want to mirror my local tree. But I will want to crossreference
    patches from the linus-tree into my own.
    *Most developers and most mirror sites don't have the money to buy $1000
    software (or more expensive), so it should be either cheap enough or
    OpenSource. And they don't need commercial support, they need a good
    README - they still are experts.
    *Bugreports become difficult for Linux, because a) more and more newbies
    send bugreports without knowing what is important and b) there are many
    experts which just don't know enough about the kernel (because they are
    busy with other projects) to send excellent reports. So this tool (or a
    connected one) should be able to force the user to enter all important
    data (by asking appropriate questions) and then redirect the report to
    the right forum/developer.
    *Most important: Linux changes in source _and_ in organization (with every
    feature added to the kernel a new group evolves and with every
    restructuring the responsibilities change). So the system should be very
    changeable - what means it should last only few weeks till there is a new
    feature in it. I know that any OpenSource project has this ability (if
    the maintainer disappeared or refuses to change it - I can ask anyone
    else to do that).

    We talk about a really _big_ OpenSource project with really _many_ backups
    all over the net. So don't talk about hypothetic cases where all the
    servers crash or some nifty admin refuses to give me the backup tapes.
    What is needed is a way to handle the source management for Linux and
    nothing else. My simple (but hard to answer) questions are these ones:

    *Which of the above abilities does BK have and which does Aegis (or any
    other free tool) have?
    *Which do they not have and how long would it take to fix that?
    *Now the heaviest: does it become easier and faster to do this work with
    that tool? Or does it only help to solve the problems which we wouldn't
    have without it?

    BTW: Larry, if you can't offer really cheap licenses to the mirror sites
    and developers then be quiet from now on, we talk about OpenSource
    development not about rich firms.

    happy thinking,
    Konrad Rosenbaum


    -
    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:54    [W:2.468 / U:0.448 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site