Re: 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 submit@xxxxxxxxxxxxxxxxxxxxxx (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 <200706172053.41806.bzolnier@xxxxxxxxx>
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. <http://permalink.gmane.org/gmane.linux.debian.devel.kernel/29740>)

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: <http://permalink.gmane.org/gmane.linux.debian.devel.kernel/29736>
...

"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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • This is [Re:] How to improve the quality of the kernel[?].
    ... Zero (tracking) done by sending patch to something ... additions automaticly gathered and inserted to e-mail sent to BTS. ... Experienced BTS users and developers. ...
    (Linux-Kernel)
  • Re: This is [Re:] How to improve the quality of the kernel[?].
    ... New Patches need tracking, review, testing ... First is mostly done by maintainers or interested individuals. ... Linus by the maintainer. ... additions automaticly gathered and inserted to e-mail sent to BTS. ...
    (Linux-Kernel)
  • Re: nvidia fb flicker
    ... >> Since the min and max value of the sync timings are equal, nvidiafb has ... Yes, your patch looks good, and will fix some of the reports I've received. ... Which leads me to conclude that Calin's display EDID, ... First, apply Linus' patch, then boot without any options. ...
    (Linux-Kernel)
  • [RFC] TASK_KILLED
    ... I've prototyped in this patch. ... There's some debug code left in here to discourage Linus from just ... with a ^C when I unplug the ethernet cord between it and the nfs server. ... goto find_page; ...
    (Linux-Kernel)
  • Re: Serial maintainership
    ... >> Please remember to send Linus a patch updating MAINTAINERS if so. ... Maintainer is cc'ed when the patch goes into -mm and when it ... It shouldn't be necessary to complain more than once. ...
    (Linux-Kernel)