Date:	Tue, 19 Jun 2007 06:06:47 +0200
From:	Oleg Verych <olecom@...wer.upol.cz>
To:	Debbugs developers <debian-debbugs@...ts.debian.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Martin Bligh <mbligh@...igh.org>,
	Natalie Protasevich <protasnb@...il.com>,
	"Fortier,Vincent [Montreal]" <Vincent.Fortier1@...gc.ca>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Adrian Bunk <bunk@...sta.de>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Oleg Verych <olecom@...wer.upol.cz>,
	Andi Kleen <andi@...stfloor.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Diego Calleja <diegocg@...il.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: This is [Re:] How to improve the quality of the kernel[?].

[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@....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@...il.com>
  sometimes happens.

  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.

* Tracking results of review (Acked-by).

  This can be mostly e-mail exchange with comments and agreements.
  "Acked-by" semantic may be implemented in form of contlol message to
  tracking system, and this system will generate e-mail confirmation
  to the patch author in form of
  "Acked-by: Developer's Name <message-id of e-mail with acke-by>"

  Thus, next patch will have this entry. And if testing of this
  version ir regression happens, there's info about who is/was
  interested/involved.

* Testing.

  Mainly same for "Tested-by"
  (newly suggested by Stefan <4675C083.6080409@...6.in-berlin.de>)

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

  Formats of that hardware profile(as system information in reportbug)
  . arch
  . chipset
  . hdd
  . vga
  ...
  in meaningful fields, and not just lspci -v[vv]. If additional info
  (-vvv) or something required, profile can be exteded.

  For kernel's sub-system information(as packed info):
  . subsystem/driver/kernel version (or similar)
  . maintainers must know what they need to see more here

|-*- back to patches -*-

  Last and not least tast cases, that everyone might came up with.

  All formats this can be agreed (or implemented and updated latter)
  and inserted automaticly.

* Commit.
  Id is recorded, patch archived. But any additions are welcome,
  regressions will pop up this patch again (reopen in BTS).

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

> In many cases, I think it tends to *sound* great to try to avoid 
> regressions in the first place - but it also sounds like one of those "I 
> wish the world didn't work the way it did" kind of things. A worthy goal, 
> but not necessarily one that is compatible with reality.

I wish perl hackers out there will join this yet-new effort. I know
there many of them out there, writing kilobytes of checkfile and
checkpatch (i've wrote in few lines of ``sed'').

BTS is written on perl, but any interoperability interface, like
stdin/stdout for python or shell hackers is worth of thinking about.

Please, see more and make useful follows ups: http://bugs.debian.org/

Please, do not (<46772321.9080602@...igh.org>)
""" I know you hate bugzilla ... but at least I can try to make that bit
    of the process work better.
""" [here's you fancy checkbox...]

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

Powered by blists - more mailing lists