mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Adrian Bunk <bunk@kernel.org>
Cc: SL Baur <steve@xemacs.org>, linux-kernel@vger.kernel.org
Subject: Re: How to reduce the number of open kernel bugs
Date: Sat, 03 May 2008 17:43:25 +0200	[thread overview]
Message-ID: <481C881D.4010708@s5r6.in-berlin.de> (raw)
In-Reply-To: <20080503112118.GK5838@cs181133002.pp.htv.fi>

Adrian Bunk wrote:
> On Sat, May 03, 2008 at 03:13:21AM -0700, SL Baur wrote:
>> On 5/2/08, Adrian Bunk <bunk@kernel.org> wrote:
>>> Just seen in the kernel Bugzilla (driver anonymized to foobar):
>>  ... An all too common sequence
>>
>> This is the kind of stuff that naturally happens when you tie performance
>> to the progression of bug reports through bug tracking systems.  It's
>> human nature.
> 
> That's a problem elsewhere, but not the problem here.
> 
> As far as I know this maintainer developed and maintaines this driver as 
> a hobby.
> 
>> It's not good, but it's human nature.  This situation is *not* unique to Linux.
>>
>> -sb (My day job is the care and feeding of a Fortune 50 company's internal bug
>> tracking system)

Adrian, what is it that you criticize?  Was it an impolite tone in the 
maintainer's responses, or do you believe that the maintainer lied to 
the reporter?

Or did the maintainer miss to do something which he would be able to and 
had the resources to do?

Or did the maintainer refuse to fulfill an obligation?

If it is one of the latter points, is it that the maintainer failed, 
according to your observation, to explain in more detail why he closed 
the bug early, in a way that a person without deep technical insight 
into the problem domain can parse?  Or to ask for information which 
would bring the bug forward?  Or to analyze the problem deeper on his 
own?  Or use the bugzilla system in a more sophisticated way (reassign, 
set status, change title... instead of closing the bug and requiring the 
reporter to create a different bug entry)?

Not as an excuse for anything, but to bring in another perspective, let 
me remind that especially maintainers who work in spare time often 
handle bugs at daytimes when the ability to analyze technical or 
procedural problems is reduced.  That's because there is little choice 
when to work on what.  (People who work professionally in this area 
hopefully do so under proper working conditions.)

Or a maintainer may not be fluent in the most efficient use of the bug 
tracker, or bug handling in general.  If so, then there need to be 
persons who assist in the bug handling.  Ideally the maintainer will 
gather experience in effective bug handling over time.  (Again, people 
who do this professionally hopefully received the necessary training. 
Also, an employer who is interested in good relationships with customers 
takes care that his contact staff is socially skilled and motivated.)

If you want maintainers to change their behavior, what are you going to 
do?  Raise awareness (like you apparently intended to by starting this 
thread and a number of other of your postings)?  Do you want to motivate 
maintainers in a negative way (make them feel guilty) or in some 
positive way?  Do you want to or have ideas how to improve process 
skills of the maintainers?  Are you going to find ways to lower 
maintainers' workload?

If you feel that obligations haven't been fulfilled in the case which 
you presented:  What is founding those obligations?

Lastly, what do you think does the number of open kernel bugs (or rather 
the inverse of it) mean to people?  Is it something like having an 
expensive looking car parked in front of the house?  I would say 
bugzilla.kernel.org is too obscure and cryptic to be able to fulfill 
that kind of role.
-- 
Stefan Richter
-=====-==--- -=-= ---==
http://arcgraph.de/sr/

  parent reply	other threads:[~2008-05-03 15:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 12:42 Adrian Bunk
2008-05-03 10:13 ` SL Baur
2008-05-03 11:21   ` Adrian Bunk
2008-05-03 12:00     ` SL Baur
2008-05-03 15:43     ` Stefan Richter [this message]
2008-05-03 15:48       ` Stefan Richter
2008-05-05 18:12       ` Adrian Bunk
2008-05-02 14:42 Parag Warudkar
2008-05-02 15:11 ` Adrian Bunk
2008-05-02 16:29 ` Daniel Hazelton
2008-05-02 17:27   ` Andi Kleen
2008-05-02 17:40     ` Daniel Hazelton
2008-05-02 17:30   ` Parag Warudkar
2008-05-02 17:44     ` Daniel Hazelton
2008-05-02 17:48       ` Rafael J. Wysocki
2008-05-02 18:18         ` Andi Kleen
2008-05-02 23:10           ` Daniel Hazelton
2008-05-02 18:01     ` Adrian Bunk
2008-05-02 18:25       ` Parag Warudkar
2008-05-02 23:15       ` Daniel Hazelton

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=481C881D.4010708@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steve@xemacs.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

Powered by JetHome