Re: This is [Re:] How to improve the quality of the kernel[?].

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.

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

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

...
|-*- 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.

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.

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

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

In Bugzilla the same works through a web interface.

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

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
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

  • Re: If you want me to quit I will quit
    ... or Linus applies patches directly bypassing the maintainers (like the ... If I am not cc'ed on a patch and have to resort to plucking it off the ... fuckup was Cc'ed to Linus (and I can't send it to -stable before it is ...
    (Linux-Kernel)
  • Re: If you want me to quit I will quit
    ... Why do other people get over 100 checkpatch fixes into the tree at once ... or Linus applies patches directly bypassing the maintainers (like the ... And Linus didn't even bother to answer what the correct path for my ... cannot be even reached, according to MAINTAINERS: ...
    (Linux-Kernel)
  • Re: If you want me to quit I will quit
    ... or Linus applies patches directly bypassing the maintainers (like the ... The patches you submit touches all parts of the kernel tree. ... Linus takes patches from people like Andrew, Al and Harvey directly, ...
    (Linux-Kernel)
  • Re: If you want me to quit I will quit
    ... or Linus applies patches directly bypassing the maintainers (like the ...
    (Linux-Kernel)
  • [patch 0/8] mutex subsystem, ANNOUNCE
    ... the patches are against Linus' latest tree. ... - fixed the %eax clobber bug noticed by Linus. ... - optimization: in the xchgcase we can avoid hitting the slowpath ...
    (Linux-Kernel)