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

[Oleg Verych <olecom@flower.upol.cz>]

[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@pts.e-mail.example.com (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@gmail.com>
> >   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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/