[arch-general] Bugs again
David C. Rankin, J.D.,P.E.
drankinatty at suddenlinkmail.com
Thu May 14 14:01:30 EDT 2009
On or about Thursday 14 May 2009 at approximately 10:50:28 Thomas Bächler
> 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
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
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
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
More information about the arch-general