public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
	torvalds@osdl.org, tony.luck@gmail.com,
	paolo.ciarrocchi@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: New (now current development process)
Date: Mon, 31 Oct 2005 03:41:02 +0100	[thread overview]
Message-ID: <200510310341.02897.ak@suse.de> (raw)
In-Reply-To: <20051030172247.743d77fa.akpm@osdl.org>

On Monday 31 October 2005 02:22, Andrew Morton wrote:

> There is nothing stopping anyone from working with the originators to get
> these things fixed up at any time.
>
> Why is it necessary for me to chase maintainers to get their bugs fixed?
>
> Why are maintainers working on new features when they have unresolved bugs?

Because zero bugs is just unrealistic and they would never get anything done
if that was the requirement? 

(especially considering that a lot of the bugs at least on x86-64 are 
hardware/firmware bugs of some sort, so often it is not really a linux
bug but just a missing ha^w^wwork^w^w^w^wfix for something else) 

I agree regressions are a problem and need to be addressed, but handling all 
non regressions on a non trivial platforms is just impossible IMHO...

Perhaps it would be nice to have better bug classification: e.g.
regression/new hardware/reported by more than one person etc.  I think
with some prioritization like that it would be much easier to keep the bugs
under control. 

Sometimes bugs are less important than others.
e.g. on x86-64 the bootmem issue was obscure at best, affecting
only a very small part of the user base. Sure the few people hit by it
will be annoyed, but trying to make everyone happy is impossible so
one has to try to just make the majority of users happy. So it was imho
ok to just revert the patch to fix ARM again and not breaking IA64 (I cannot 
assess how many users were on ARM/IA64 affected)  for the next release and 
try to sort it out later.

Regressions are important, everything else has to be prioritized based on the 
impact on the user base (and this doesn't necessarily mean the most noisy 
part of the userbase) 

Perhaps some people could volunteer to set some flags in bugzilla for obvious 
things, like regression or new hardware or missing basic information or for 
really old kernel and no report for a new one and that could be used to 
filter the queries better. Should be an relatively easy task.

-Andi

  reply	other threads:[~2005-10-31  1:42 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-29 17:26 New (now current development process) Paolo Ciarrocchi
2005-10-29 18:57 ` Tony Luck
2005-10-29 19:51   ` Russell King
2005-10-29 20:28     ` Linus Torvalds
2005-10-29 20:44       ` Akula2
2005-10-29 23:28         ` Greg KH
2005-10-29 22:29       ` Andi Kleen
2005-10-29 22:37         ` Russell King
2005-10-30 19:12           ` Andrew Morton
2005-10-30 21:43             ` Russell King
2005-10-30 22:31               ` Andrew Morton
2005-10-30 22:45                 ` Russell King
2005-10-30 22:55                   ` Andrew Morton
2005-10-30 23:17                     ` Russell King
2005-10-31  0:48             ` Andi Kleen
2005-10-31  0:16               ` Russell King
2005-10-31  1:22                 ` Andrew Morton
2005-10-31  2:41                   ` Andi Kleen [this message]
2005-10-31  6:34                     ` Zwane Mwaikambo
2005-10-31  7:07                     ` Andrew Morton
2005-10-31 23:58                     ` Roman Zippel
2005-11-01  0:05                       ` Andrew Morton
2005-11-01  0:13                         ` Linus Torvalds
2005-11-01  0:34                           ` Andrew Morton
2005-11-01  0:59                             ` Grant Coady
2005-11-01 14:08                             ` Adrian Bunk
2005-11-01 15:15                             ` Nix
2005-11-01 15:26                             ` Bill Davidsen
2005-11-02  5:01                             ` Roland Dreier
2005-11-02  5:43                               ` Linus Torvalds
2005-11-02  5:56                                 ` Roland Dreier
2005-11-02  6:05                                   ` Linus Torvalds
2005-11-02  6:15                                     ` Roland Dreier
2005-11-02 15:54                                       ` Linus Torvalds
2005-11-02 17:48                                         ` Dave Jones
2005-11-02 18:12                                           ` Adrian Bunk
2005-11-02 20:11                                           ` David Lang
2005-11-02 22:31                                             ` Sam Ravnborg
2005-11-03 18:54                                               ` Andi Kleen
2005-11-02 23:11                                     ` Rob Landley
2005-11-04 22:08                                     ` Tim Bird
2005-11-04 22:35                                       ` Andi Kleen
2005-11-04 23:33                                         ` Tim Bird
2005-11-02 15:41                             ` Andreas Kleen
2005-11-01  7:52                           ` Russell King
2005-11-01  9:09                           ` Rob Landley
2005-11-01 14:15                           ` Adrian Bunk
2005-11-01  0:17                         ` Roman Zippel
2005-11-01  0:34                           ` Jesse Barnes
2005-10-31  1:10               ` Andrew Morton
2005-10-31  5:05               ` Rob Landley
2005-10-31  7:17                 ` Andrew Morton
2005-10-31  8:47                   ` Rogério Brito
2005-10-31  9:54                     ` Andrew Morton
2005-11-02  5:04                   ` Martin J. Bligh
2005-10-30 21:32         ` Theodore Ts'o
2005-10-31  0:45           ` Andi Kleen
2005-10-31  0:18             ` Al Viro
2005-10-31  3:14               ` Paul Jackson
2005-10-31  3:34                 ` Al Viro
2005-10-31  6:17                   ` Paul Jackson
2005-10-31  7:22                   ` Andrew Morton
2005-10-31  7:27                     ` Al Viro
2005-10-31  8:19                       ` Paul Jackson
2005-11-02  4:53                       ` Martin J. Bligh
2005-11-02  4:49               ` Martin J. Bligh
2005-10-31  4:52             ` Rob Landley
2005-11-02 14:44               ` Andreas Kleen
2005-10-30  1:12       ` Tony Luck
2005-10-31  6:41       ` Willy Tarreau
2005-11-07  4:54         ` Eric Sandall
2005-11-07 16:12           ` Krzysztof Halasa
2005-11-07 17:11             ` Christopher Friesen
2005-11-07 17:22               ` Linus Torvalds
2005-11-07 17:28                 ` Linus Torvalds
2005-11-07 20:34                   ` Willy Tarreau
2005-11-07 18:25               ` Krzysztof Halasa
2005-10-30  0:37 ` Jesper Juhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200510310341.02897.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paolo.ciarrocchi@gmail.com \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=tony.luck@gmail.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox