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
