On Thu, 2009-05-14 at 16:42 +0200, ludovic coues wrote:

for me, a bug tracker is for tracking bug. For an upstream issue, the bug is spotted, reported to the bug tracker, and flagged upstream. Why it'll be closed at this point ?

While there no patch to correct the bug, the bug is still here, and need to be tracked. So closing a bug report before resolving the bug is Bad, even if it's an upstream issue.

That's how I see bug tracker and I wonder why it's not like this. Am I wrong ?

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 share your thoughts about this invalid "upstream" closing thing. I don't think this option should ever be abused to simply get rid of bugs.

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

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

2009/5/14 Angel Velásquez <angvp@archlinux.com.ve>:

Well, sometimes and this time I have to point you Jan (nothing personal, you are my hero dude), but, why? see this bug for example [0].. You closed it with the reason "works for me" but you didn't research a lot, I had this exact problem and I solved it downgrading, then I found a pach in the forum [1], _I should mention that the forum is not the bugtracker and the people who wrote there should report the bug in the bugtracker_ but the maintainer should eventually research in google about the described error.

[0] http://bugs.archlinux.org/task/14096?string=gnome-terminal&project=1&search_name=&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

[1] http://bbs.archlinux.org/viewtopic.php?id=69153

In his last comment, JGC proposed this fix : "Launch your window manager or whatever you're using from .xinitrc using dbus-launch --exit-with-session and you should be fine." In his last comment, the user reports : "Your fix worked" Then JGC closes the bug. What is wrong with this?

On Thu, May 14, 2009 at 10:35 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:

On Thu, May 14, 2009 at 6:46 AM, Damjan Georgievski <gdamjan@gmail.com> wrote:

...

Sorry to bring this again,  but something has to change in the way bugs are handled in Arch.

I've open this bug report http://bugs.archlinux.org/task/13905 about the awesome package in community.

The package maintainer just closes the bug, not solving it, claiming it's upstream, and not even investigating the problem. He suggests I ask upstream.

Ok, I play a good citizen, I do ask upstream, we find the problem, a sollution is found - it turns out the PKGBUILD was wrong from the begining - but still I submit a patch to awesome so that building it is much easier.

I request reopening the bug .. it's a small text-area, not very usable, so I just write "New information" .. since the bug was closed with "You may want to ask upstream why they install those files by default.".

And then I get the answer: Reason for denial: You need to be more specific that "New information" in a reopen request...

Now, it's not like I enjoy hanging out in the bug system opening bugs, investigating them, hoping to improve ArchLinux's packages.. and I don't see how I could've deserved this behaviour.

The bug report shouldn't have been closed in the first place, since the problem was not even solved.

It's worth noting that the people who handle re-open requests are not necessarily the one assigned to the bug.

And another note: when reopening a report, the text of the reopen request is added as a comment. It may be a small text area, but it does allow for more text than it seems

...

The bug report shouldn't have been closed in the first place, since the problem was not even solved.

It's worth noting that the people who handle re-open requests are not necessarily the one assigned to the bug.

I did notice that .. and also I didn't want to attack anybody personally, I think the only thing missing is a bit of culturre or maybe guidance of how bugs need to be handled. -- damjan

This discussion never seems to get old. First of all: The guidlines is a stub, maybe someone should update it? http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines I am not saying it doesn't provide enough information, but when people keeps asking why's and whatnot, maybe it doesnt? Secondly: Do the devs have an internal guidline? If not, maybe they should. Thirdly: Why are users encouraged to report to the ML and the forums beforehand? I don't see any practical reason in having several bit's and pieces of information spread around. A bugtracker should be used for that, it's possible to post comments in it, isn't it? Having one clear system for users to post bugs will help gain population and give encouragement, if a user have to go through several different organs for something like this, the majority of users will most likely not do it. - Sad to say, but it IS the truth. And lastly: I am not only talking for myself here, but clearly when putting alot of work into something which is broken, and fixing it, reporting it as a bug and even providing a solution you would expect to at least get some feedback. Sorry for spamming. -J On Fri, May 15, 2009 at 10:17 AM, Allan McRae <allan@archlinux.org> wrote:

Damjan Georgievski wrote:

...

The bug report shouldn't have been closed in the first place, since

...

...

the problem was not even solved.

It's worth noting that the people who handle re-open requests are not necessarily the one assigned to the bug.

I did notice that .. and also I didn't want to attack anybody personally, I think the only thing missing is a bit of culturre or maybe guidance of how bugs need to be handled.

I'll put my hand up as the evil person who denied your reopen request. I was hoping my suggestion to add more information to the reopen request would results in a new request with some details. I didn't realize that you thought only a small amount of text could be provided, so that was a bit of a fail on my behalf.

Allan

-- http://divineintervention.no