[lkml]   [2007]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: This is [Re:] How to improve the quality of the kernel[?].
    [Dropping noise for Debbugs, because interested people may join via Gmane]

    On Tue, Jun 19, 2007 at 02:48:55PM +0200, Adrian Bunk wrote:
    > On Tue, Jun 19, 2007 at 06:06:47AM +0200, Oleg Verych wrote:
    > > [Dear Debbug developers, i wish your ideas will be useful.]
    > >
    > > * From: Linus Torvalds
    > > * Newsgroups: gmane.linux.kernel
    > > * Date: Mon, 18 Jun 2007 17:09:37 -0700 (PDT)
    > > >
    > > > On Mon, 18 Jun 2007, Martin Bligh wrote:
    > > >>
    > > >> Sorry to be a wet blanket, but I've seen those sort of things
    > > >> before, and they just don't seem to work, especially in the
    > > >> environment we're in with such a massive diversity of hardware.
    > > >
    > > > 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 (like BTS now). Notifications will
    > > be sent to intrested maintainers (if meta-information is ok) or testers
    > > (see below)
    > >
    > > First is mostly done by maintainers or interested individuals.
    > > Result is "Acked-by" and "Cc" entries in the next patch sent. Due to
    > > lack of tracking this things are done manually, are generally in
    > > trusted manner. But bad like <>
    > > sometimes happens.
    > The goal is to get all patches for a maintained subsystem submitted to
    > Linus by the maintainer.
    > > When patch in sent to this PTS, your lovely
    > > checkpatch/check-whatever-crap-has-being-sent tools can be set up as
    > > gatekeepers, thus making impossible stupid errors with MIME coding,
    > > line wrapping, whatever style you've came up with now in checking
    > > sent crap.
    > The -mm kernel already implements what your proposed PTS would do.

    Having all-in-one patchset, like -mm is easy thing to provide
    interested parties with "you know what you have -- crazy development"

    However [P]TS is tracking, recording, organizing tool. {1} Andrew's cron
    daemon easily can run script to check status of particular patch (cc,
    tested-by, acked-by). If patch have no TS ID, Andrew's watchdog is
    barking back to patch originator (with polite asking to send patch as:

    * TS as "To:" target
    * patch author as "Cc:" target, this is useful to require:
    . author can check that copy himself with text-only pager program
    (to see any MIME coding crap)
    . preventing SPAM
    * maybe somebody else in Cc or Bcc.)

    > Plus it gives testers more or less all patches currently pending
    > inclusion into Linus' tree in one kernel they can test.

    Crazy development{0}. Somebody knows, that comprehensively testing
    hibernation is their thing. I don't care about it, i care about foo, bar.
    Thus i can apply for example lguest patches and implement and test new
    asm-offset replacement, *easily*. Somebody, as you know, likes new fancy
    file system, and no-way other. Let them be happy testing that thing
    *easily*. Because another fancy NO_MHz will hang their testing bench
    right after best ever speed results were recorded.

    > The problem are more social problems like patches Andrew has never heard
    > of before getting into Linus' tree during the merge window.

    Linus' watchdog, as well, asking for valid patch id, or just doesn't
    care (in similar manner Linus does :).

    So far no human is involved in social things. Do you agree?

    Human power is worth and needed in particular patch discussion and
    testing under the participation (by Cc, acking, test-ok *e-mails*) of
    tracking system.

    > >...
    > > |-*- Feature Needed -*-
    > > Addition, needed is hardware user tested have/had/used. Currently
    > > ``reportbug'' tool includes packed specific and system specific
    > > additions automaticly gathered and inserted to e-mail sent to BTS.
    > > (e.g. <>)
    > The problem is that most problems don't occur on one well-defined
    > kind of hardware - patches often break in exactly the areas the patch
    > author expected no problems in.

    I tried to test that new fancy FS, and couldn't boot because of
    yet-another ACPI crap. See theme{0}?

    Overall testing, like Andrew does, is doubtless brave thing, but he have
    more time after {1}, isn't it?

    > And in many cases a patch for a device driver was written due to a bug
    > report - in such cases a tester with the hardware in question is already
    > available.

    Tracking all possible testers (for next driver update, for example) is
    in question.

    > >...
    > > > but in the end, it needs to also be easy and painfree to the people
    > > > involved, and also make sure that any added workflow doesn't require
    > > > even *more* load and expertise on the already often overworked
    > > > maintainers..
    > >
    > > Experienced BTS users and developers. Please, correct me if i'm wrong.
    > > At least e-mail part of Debian's BTS and whole idea of it is *exactly*
    > > what is needed. Bugzilla fans, you can still use you useless pet,
    > > because Debian developers have done things, to track and e-mail states
    > > of bugs: <>
    > >...
    > "useless pet"?
    > Be serious.
    > How many open source projects use Bugzilla and how many use the Debian BTS?
    > And then start thinking about why the "useless pet" has so many more
    > user...

    I might be stupid, but i faced it. On my amd64 512M laptop i *cannot* run
    mozillka any more, for example! And i don't care, because Linus said his
    opinion and i fully agree with him.

    > The Debian BTS requires you to either write emails with control messages
    > or generating control messages with external tools.

    Awesome!!! Are you wrote this reply to me by

    > In Bugzilla the same works through a web interface.

    web interface? If you did .........</dev/random dd bs=1 count=13.....
    Actually you didn't ;)

    > I know both the Debian BTS and Bugzilla and although they are quite
    > different they both are reasonable tools for their purpose.

    As you just might have seen here, i was talking about organizing,
    tracking, hopefully saving and redirecting useful main power. And i don't
    bother search e-mails i saw about Bugzilla's BD from many other prominent
    developers. I just know that, not from my dream or physical vacuum.

    Basic concept of Debian BTS is what i've discovered after many useless
    hours i spent in Bugzilla. And this is mainly because of one basic
    important thing, that nobody acknowledged (for newbies, like me):

    * E-Mail with useful MUAs, after it got reliable delivery MTAs with qmail
    (or exim) is the main communication toolset.

    Can't you see that from Linux's patch sending policy?

    I also what to reply to myself about why LKML was established and
    USENET (news) was abandoned.

    To control and to keep running *your* _main communication toolset_
    (read as "your user,developer feedback").

    I just couldn't realize that, because i grew up in free web e-mail, after
    having set up my own server with MTA and real e-mail and after
    discovering Gmane (really mind-blowing evolution of the e-mail system!)

    > cu
    > Adrian
    > --
    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: 2007-06-19 15:55    [W:0.052 / U:125.092 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site