[arch-general] Bugs again

[David C. Rankin, J.D.,P.E.]

On or about Thursday 14 May 2009 at approximately 10:50:28 Thomas Bächler 
composed:
> Jan de Groot schrieb:
> > The only valid reason I see for closing a bug as upstream, is when
> > upstream made a decision in the software which is reported as bug by the
> > user. An example of this is excluding evince from the menus by using
> > NoDisplay=True in the .desktop file. This bug is opened now and then,
> > and it's either closed as duplicate of the previous one, or it's closed
> > as upstream. Upstream decided to remove it from the menus because it's a
> > viewer application that can't do anything else than file->open, so let
> > them handle the bugreports for that.
>
> I am always tempted to close nvidia bugs as "upstream", as we can do
> nothing about them and there is no public bugtracker I know of. But you
> are right, most of the time we should at least track the bugs even if
> the are upstream.

	Over the past several years I have contributed to over 120 reports to Novell 
concerning their distro. One of the most frustrating things, and part of the 
reason I am here, was the utter missmanagement of bug reports and the 
intentional closure of valid bugs as WONTFIX or UPSTREAM purely for the 
apparent reason of bettering the open/resolved statistics or due to the 
conscious decision to leave things broken if the issue was one that would not 
directly impact its future SLES or SLED commercial product. The biggest 
problem, and the one that left the worst taste in my mouth, was the closures 
without even a two-sentence explanation of 'why'.

	That is why I really like Arch. It is a pure distro that doesn't suffer the 
ill effects of being a puppet-distro for a corporate master and therefore bug 
handling with Arch isn't subject to pressure to leave things broken in a 
supported release because the bug won't impact a future commercial offering.

	However, one of the major strengths, or weaknesses, of any distro is 
bughandling. We are all hear due to our support of opensource and to do our 
part to better it and Arch itself. Out of the Arch user base, there will be 
(give or take) about 10% that contribute by taking the time to file bug 
reports. Of those that file the bug reports, close to 95% do not have 
technical expertise to author a patch or fix the problem, myself included, 
and must rely on the developers to remedy the problem.

	That's where tracking, handling, resolving, moving upstream (or whatever else 
you want to call it) becomes critically important. As Damjan expressed, quite 
diplomatically, nothing is more frustrating to a contributor than taking the 
time to identify, investigate, analyze and properly report a bug just to find 
out that the bug has been 'closed' without the problem being fixed and 
without even a two-sentence explanation of 'why'. It is a slap in the face so 
to speak.

	Now we all realize that there are some things that can't be fixed 
immediately, or that do not make sense to fix in the present package due to 
whatever reason (current status of rewrite, etc...), and the fix must be 
delayed to the next major release of the package upstream.

	Any distro must carefully balance the upstream decision and should have some 
way of making that determination in a way that is not arbitrary and a way to 
explain 'why'. At that point, as discussed in this thread, there must be 
continuity in separating and tracking those bugs that are moved into the 
category to be fixed later and those that are left in the active queue to be 
presently worked.

	If a bug is moved into the category that will be fixed upstream, there 
is 'always' a 'reason' for that decision being made. The simplest way to 
avoid the misunderstanding over why a bug is marked as upstream, is simply to 
give the two-sentence reason for 'why' that decision has been made. Then if 
there is "More Information", an alternative patch or fix that can be 
implemented relatively easily, there needs to be a way to have the upstream 
decision reconsidered to evaluate if the fix can be implemented. In this 
situation, Damjan's report of "New information" should have triggered that 
type of reconsideration. That mechanism in the process must exist and must be 
made available to the contributors, especially that 5% that can provide the 
needed fix.

	If, after consideration, the fix can't be implemented and the bug will remain 
an upstream issue, then the two-sentence explanation of 'why' goes a long, 
long way toward preventing the misunderstanding we are discussing here.

	Often overlooked in distro evaluation, this area of bug handling is one of 
the major areas that can set a distro apart from the rest of the pack. From 
what I can tell from my short time here, Arch does a very good job, but this 
issues provides us all an opportunity to review whether we can make any 
improvements to this part of Arch's bug tracking process.

	From my experience, the most critical, and easy, improvement to be made in 
this area is just to communicate 'why'. That two-sentence explanation back to 
the contributor and the opportunity to consider a simple patch goes a long, 
long way toward making a distro shine.

	Now all of the above is just my opinion on the issue and will look like a 
bunch of idle rambling to most, but if you sift through it, there just may be 
a perl of wisdom to pick out. (remember, even a blind squirrel finds a nut 
every once in a while ;-)


-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com