Trac policy on "won't fix" issue
Suppose there's an issue in Trac about program_options library. The issue is such that I personally have no hope of *ever* fixing it. What should be done to such issue: 1. Close it as won't fix. 2. Keep it open. (1) has the advantage that the issue won't show up in my searched, making life easier for me, but it reduces chances that somebody else will accidentally see and fix it. OTOH, the chances of such fix are also pretty low. So, I personally prefer (1), but I also think we should have a single consistent meaning of what open issue in Trac means, and under what cases an issue that is not actually fixed can be closed. Any comments? - Volodya
Vladimir Prus wrote:
Suppose there's an issue in Trac about program_options library. The issue is such that I personally have no hope of *ever* fixing it. What should be done to such issue:
1. Close it as won't fix. 2. Keep it open.
If the issue won't be fixed, "won't fix" seems the only reasonable choice. If the issue is sufficiently important, a section "known issues" in the documentation should list it. - Thomas
I've got a couple of those. What I really need is an option "can't fix". Since I don't have that I use "won't fix". About half the time, the original poster reopens it because he thinks I should fix it anyway. At this point I just leave it open and move on. Robert Ramey Vladimir Prus wrote:
Suppose there's an issue in Trac about program_options library. The issue is such that I personally have no hope of *ever* fixing it. What should be done to such issue:
1. Close it as won't fix. 2. Keep it open.
(1) has the advantage that the issue won't show up in my searched, making life easier for me, but it reduces chances that somebody else will accidentally see and fix it. OTOH, the chances of such fix are also pretty low.
So, I personally prefer (1), but I also think we should have a single consistent meaning of what open issue in Trac means, and under what cases an issue that is not actually fixed can be closed.
Any comments?
- Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tuesday 26 May 2009 18:52:18 Robert Ramey wrote:
What I really need is an option "can't fix". Since I don't have that I use "won't fix". About half the time, the original poster reopens it because he thinks I should fix it anyway. At this point I just leave it open and move on.
TRAC allows you (or, rather, the administrator) to configure what resolutions are possible. Invoke 'trac-admin <path to the trac environment>' and use its built-in help functionality. That said, I would leave such bugs open and thus make them easier to find, otherwise you get the gun of closing duplicate bug reports. Uli
On Tue, May 26, 2009 at 9:53 PM, Ulrich Eckhardt <doomster@knuut.de> wrote:
On Tuesday 26 May 2009 18:52:18 Robert Ramey wrote:
What I really need is an option "can't fix". Since I don't have that I use "won't fix". About half the time, the original poster reopens it because he thinks I should fix it anyway. At this point I just leave it open and move on.
Perhaps you should reset them to won't fix after a couple of months again?
I would leave such bugs open and thus make them easier to find,
Are they really easier to find this way?
otherwise you get the gun of closing duplicate bug reports.
That should not be a reason for leaving tickets as open. I'd say that it's more important to know what problems are actually under consideration to fix. Why should "open" have the extra meaning "this will never be implemented"? /$
Henrik Sundberg wrote:
On Tue, May 26, 2009 at 9:53 PM, Ulrich Eckhardt <doomster@knuut.de> wrote:
On Tuesday 26 May 2009 18:52:18 Robert Ramey wrote:
What I really need is an option "can't fix". Since I don't have that I use "won't fix". About half the time, the original poster reopens it because he thinks I should fix it anyway. At this point I just leave it open and move on.
Perhaps you should reset them to won't fix after a couple of months again?
I would leave such bugs open and thus make them easier to find,
FYI - in these cases (there are only 2) the poster and I can't agree that it's a bug. I say it isn't he says it is - so I just leave it at that. It's not a big deal.
Are they really easier to find this way?
otherwise you get the gun of closing duplicate bug reports.
That should not be a reason for leaving tickets as open. I'd say that it's more important to know what problems are actually under consideration to fix. Why should "open" have the extra meaning "this will never be implemented"?
/$ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tuesday 26 May 2009 22:16:46 Henrik Sundberg wrote:
On Tue, May 26, 2009 at 9:53 PM, Ulrich Eckhardt <doomster@knuut.de> wrote:
On Tuesday 26 May 2009 18:52:18 Robert Ramey wrote:
What I really need is an option "can't fix". Since I don't have that I use "won't fix". About half the time, the original poster reopens it because he thinks I should fix it anyway. At this point I just leave it open and move on.
Perhaps you should reset them to won't fix after a couple of months again?
I would leave such bugs open and thus make them easier to find,
Are they really easier to find this way?
If I find something that strikes me as odd, I browse the open bug reports and file one myself if it isn't listed yet. Actually, this is only the second step, the first is that I look at the FAQ or list of known issues in the documentation for the module to see if the misbehavior I perceive is known and possibly even intended. However, I don't look in the "closed" issues. Depending on how the issue search is configured in TRAC, the "search for open issues" could well include unfixable bugs, so it isn't strictly necessary to mark the issue with the "open" state, an "unfixable" state would also work then. Actually, in different words, maybe it just takes a few other possibilities for the state of an issue, in order to classify different states of "open", like "open but unfixable". Note that TRAC allows attaching arbitrary keywords to an issue, maybe that would also be an option do do that.
otherwise you get the gun of closing duplicate bug reports. [Note: should have read "fun", not "gun"]
That should not be a reason for leaving tickets as open. I'd say that it's more important to know what problems are actually under consideration to fix. Why should "open" have the extra meaning "this will never be implemented"?
"open" means just that, and it classifies the current state of the issue. If something is a bug but not fixable for whatever reason its current state is "open" because it is not fixed at the moment. The fact that it never will be fixed is a different thing, which should obviously be justified in the ticket, but it doesn't change the state from "open" automatically. Uli
Ulrich Eckhardt wrote:
On Tuesday 26 May 2009 22:16:46 Henrik Sundberg wrote:
On Tue, May 26, 2009 at 9:53 PM, Ulrich Eckhardt <doomster@knuut.de> wrote:
On Tuesday 26 May 2009 18:52:18 Robert Ramey wrote:
What I really need is an option "can't fix". Since I don't have that I use "won't fix". About half the time, the original poster reopens it because he thinks I should fix it anyway. At this point I just leave it open and move on.
Perhaps you should reset them to won't fix after a couple of months again?
I would leave such bugs open and thus make them easier to find,
Are they really easier to find this way?
If I find something that strikes me as odd, I browse the open bug reports and file one myself if it isn't listed yet. Actually, this is only the second step, the first is that I look at the FAQ or list of known issues in the documentation for the module to see if the misbehavior I perceive is known and possibly even intended. However, I don't look in the "closed" issues. Depending on how the issue search is configured in TRAC, the "search for open issues" could well include unfixable bugs, so it isn't strictly necessary to mark the issue with the "open" state, an "unfixable" state would also work then.
Actually, in different words, maybe it just takes a few other possibilities for the state of an issue, in order to classify different states of "open", like "open but unfixable". Note that TRAC allows attaching arbitrary keywords to an issue, maybe that would also be an option do do that.
otherwise you get the gun of closing duplicate bug reports. [Note: should have read "fun", not "gun"]
That should not be a reason for leaving tickets as open. I'd say that it's more important to know what problems are actually under consideration to fix. Why should "open" have the extra meaning "this will never be implemented"?
"open" means just that, and it classifies the current state of the issue. If something is a bug but not fixable for whatever reason its current state is "open" because it is not fixed at the moment.
There are different definitions of "open". For me, "open" issue is an action item, which implies that issue must be actionable upon. - Volodya
Hi, ----- Original Message ----- From: "Vladimir Prus" <vladimir@codesourcery.com> To: <boost@lists.boost.org> Sent: Wednesday, May 27, 2009 8:04 AM Subject: Re: [boost] Trac policy on "won't fix" issue
Ulrich Eckhardt wrote:
On Tuesday 26 May 2009 22:16:46 Henrik Sundberg wrote:
On Tue, May 26, 2009 at 9:53 PM, Ulrich Eckhardt <doomster@knuut.de> wrote:
On Tuesday 26 May 2009 18:52:18 Robert Ramey wrote:
What I really need is an option "can't fix". Since I don't have that I use "won't fix". About half the time, the original poster reopens it because he thinks I should fix it anyway. At this point I just leave it open and move on.
Perhaps you should reset them to won't fix after a couple of months again?
I would leave such bugs open and thus make them easier to find,
Are they really easier to find this way?
If I find something that strikes me as odd, I browse the open bug reports and file one myself if it isn't listed yet. Actually, this is only the second step, the first is that I look at the FAQ or list of known issues in the documentation for the module to see if the misbehavior I perceive is known and possibly even intended. However, I don't look in the "closed" issues. Depending on how the issue search is configured in TRAC, the "search for open issues" could well include unfixable bugs, so it isn't strictly necessary to mark the issue with the "open" state, an "unfixable" state would also work then.
Actually, in different words, maybe it just takes a few other possibilities for the state of an issue, in order to classify different states of "open", like "open but unfixable". Note that TRAC allows attaching arbitrary keywords to an issue, maybe that would also be an option do do that.
otherwise you get the gun of closing duplicate bug reports. [Note: should have read "fun", not "gun"]
That should not be a reason for leaving tickets as open. I'd say that it's more important to know what problems are actually under consideration to fix. Why should "open" have the extra meaning "this will never be implemented"?
"open" means just that, and it classifies the current state of the issue. If something is a bug but not fixable for whatever reason its current state is "open" because it is not fixed at the moment.
There are different definitions of "open". For me, "open" issue is an action item, which implies that issue must be actionable upon.
What about "suspended"? From the developer point of view it is clear that there is nothing to do until the reasons for which the ticket was suspended change. From the point of view of the user, a suspended ticket can be considered as open. Best, Vicente
On Wednesday 27 May 2009 08:13:25 vicente.botet wrote:
Ulrich Eckhardt wrote: [...]
"open" means just that, and it classifies the current state of the issue. If something is a bug but not fixable for whatever reason its current state is "open" because it is not fixed at the moment.
There are different definitions of "open". For me, "open" issue is an action item, which implies that issue must be actionable upon.
What about "suspended"? From the developer point of view it is clear that there is nothing to do until the reasons for which the ticket was suspended change. From the point of view of the user, a suspended ticket can be considered as open.
+1 Good idea. Uli
2009/5/27 Ulrich Eckhardt <doomster@knuut.de>:
"open" means just that, and it classifies the current state of the issue. If something is a bug but not fixable for whatever reason its current state is "open" because it is not fixed at the moment. The fact that it never will be fixed is a different thing, which should obviously be justified in the ticket, but it doesn't change the state from "open" automatically.
I strongly disagree. An issue (bug) is only open when there's a decision to be made about what to do with it. When you've decided that you won't fix it it doesn't so much fix the bug but it does close the issue. People finding bugs that are in the product should look into won't fix, open and related tags; issues not being open doesn't mean they're fixed. Maybe it's possible to change the default search (or default search-here-for-your-to-be-reported-bug) target to include those targets by default? Kind regards, Peter
On Wed, May 27, 2009 at 8:32 AM, Peter Bindels <dascandy@gmail.com> wrote:
2009/5/27 Ulrich Eckhardt <doomster@knuut.de>:
"open" means just that, and it classifies the current state of the issue. If something is a bug but not fixable for whatever reason its current state is "open" because it is not fixed at the moment. The fact that it never will be fixed is a different thing, which should obviously be justified in the ticket, but it doesn't change the state from "open" automatically.
I strongly disagree. An issue (bug) is only open when there's a decision to be made about what to do with it. When you've decided that you won't fix it it doesn't so much fix the bug but it does close the issue. People finding bugs that are in the product should look into won't fix, open and related tags; issues not being open doesn't mean they're fixed.
And the maintainer is the one that decides about accepted Boost components. The issue is not open in the eyes of the maintainer, and should therefore not be marked as open. "Won't Fix" with the reason "Can't Fix" in the ticket is very clear. Misbehaving users can report anything anyway.
Ulrich Eckhardt <doomster <at> knuut.de> writes:
"open" means just that, and it classifies the current state of the issue. If something is a bug but not fixable for whatever reason its current state is "open" because it is not fixed at the moment. The fact that it never will be fixed is a different thing, which should obviously be justified in the ticket, but it doesn't change the state from "open" automatically.
Another possibility: Use a special milestone, e.g. "never", to indicate that the maintainer doesn't believe it should/will ever be resolved. Thus, the bug can stay open but still be trivial for maintainers to filter out. Whatever is decided, I hope that the standard operating procedure is that when the bug is moved to this "won't fix" state, a clear reason is given. I'll admit that in other projects I'm one of those who, if the bug is closed with no (or poor) reasoning, will re-open bugs with a question as to why it was marked as such instead of being deferred. Often sound reasoning can be provided, but occasionally the bug gets closed as "won't fix" simply because the person doing the triaging didn't realize they had the option to defer to a later release. This is a sad way to lose track of a bug. Anyhow, I hope this idea helps, -Ryan
participants (9)
-
Henrik Sundberg -
Peter Bindels -
Robert Ramey -
Ryan Gallagher -
Thomas Klimpel -
Ulrich Eckhardt -
vicente.botet -
Vladimir Prus -
Vladimir Prus