lkml.org 
[lkml]   [2007]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: This is [Re:] How to improve the quality of the kernel[?].
    On Tue, 19 Jun 2007, Oleg Verych wrote:
    > * From: Linus Torvalds
    > * Newsgroups: gmane.linux.kernel
    > * Date: Mon, 18 Jun 2007 17:09:37 -0700 (PDT)
    >
    > > I do agree. It _sounds_ like a great idea to try to control the
    > > flow of patches better,
    >
    > There were some ideas, i will try to summarize:
    >
    > * New Patches (or sets) need tracking, review, testing
    >
    > Zero (tracking) done by sending (To, or bcc) [RFC] patch to something
    > like submit@pts.e-mail.example.com (like BTS now). Notifications will
    > be sent to intrested maintainers (if meta-information is ok) or testers
    > (see below)

    The BTS, while fairly good at tracking issues for distributions made
    up of thousands of packages (like Debian), is rather suboptimal for
    dealing with the workflow of a single (relatively) monolithic entity
    like the linux kernel.

    Since the ultimate goal is presumably to apply a patch to a git tree,
    some sort of system which is built directly on top of git (or
    intimately intertwined) is probably required. Some of the metrics that
    the BTS uses, like the easy ability to use mail to control bugs may be
    useful to incorporate, but I'd be rather surprised if it could be made
    to work with the kernel developer's workflow as it exists now.

    It may be useful for whoever ends up designing the patch system to
    take a glimpse at how it's done in debbugs, but since I don't know how
    the workflow works now, and how people want to have it work in the
    end, I can't tell you what features from debbugs would be useful to
    use.

    Finally, at the end of the day, my own time and effort (and the
    primary direction of debbugs development) is aimed at supporting the
    primary user of debbugs, the Debian project. People who understand (or
    want to understand) the linux kernel team's workflow are the ones who
    are going to need to do the heavy lifting here.


    Don Armstrong

    --
    N: Why should I believe that?"
    B: Because it's a fact."
    N: Fact?"
    B: F, A, C, T... fact"
    N: So you're saying that I should believe it because it's true.
    That's your argument?
    B: It IS true.
    -- "Ploy" http://www.mediacampaign.org/multimedia/Ploy.MPG

    http://www.donarmstrong.com http://rzlab.ucr.edu
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-19 15:45    [W:0.024 / U:0.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site