lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <481C881D.4010708@s5r6.in-berlin.de>
Date:	Sat, 03 May 2008 17:43:25 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Adrian Bunk <bunk@...nel.org>
CC:	SL Baur <steve@...acs.org>, linux-kernel@...r.kernel.org
Subject: Re: How to reduce the number of open kernel bugs

Adrian Bunk wrote:
> On Sat, May 03, 2008 at 03:13:21AM -0700, SL Baur wrote:
>> On 5/2/08, Adrian Bunk <bunk@...nel.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/
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ