[arch-general] Bugs again

Thu May 14 15:57:47 EDT 2009

On Thu, May 14, 2009 at 01:01:30PM -0500, David C. Rankin, J.D.,P.E. wrote:
> 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'.

Its the job of the *submitter*, to FIRST file the bug upstream if there
isn't one already & then open a report on the Arch Linux package in
which he/she should include the link to upstream report.
Furthermore cause of the reason i describe below in [1].
If that happened in this occasion we would have to read huge emails like
this one again.
Many of the bugs reported to the Arch Linux flyspray dont get solved
until there is a new version of the package out, or if the developer who
maintains the application backports a patch already applied in the
upstream development tree.
This is about upstream bygs of course. If the user is unsure if the bug
is upstream or not he can first open a thread on the Arch forum, the mailing
list, and even the resources of the project he wants to report the bug
against.
But in all cases, he must show *interest* and *invest time* into it.
If the user shows interest before he submits a report, the developer
will most likely appreciate it more.
Its not easy to close without further discussion a well documented
report.

> 
> 	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.

You seem to like Arch for the wrong reasons IMO. Although its certainly
comforting that you do like it. :)
A main difference from a users point of view, and relevant to the topic,
is not that its not a puppet-distro. Although that fact definately has
its value.
[1] Its the fact that Arch *strives* to distribute the sources that come
from upstream. It doesnt patch software to get more features from it and
then distributing it with the same name.
Most of us know where that leads. Remember Debian & openssh, Arch
with Ion3, Mozilla firefox in Ubuntu.

> 
> 	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

Sorry i just read the first two paragraphs. Apologies.
Please tru to avoid such long emails when you have the option.

-- 
Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://www.archlinux.org/pipermail/arch-general/attachments/20090514/9c383a15/attachment.pgp>