Policy: "preferred" method of reporting bugs
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Fri, Nov 02, 2007 at 10:14:11PM -0400, David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach?
I would strongly prefer to combine both. Using a web interface is a very slow process, sometimes you even loss your text, you don't have access to your preferred editor such as vim, ... Why not add an email interface similar as Debian does (www.debian.org/Bugs) which creates a bug report in trac using some special header strings such as library:, version:, ... Not sure whether such an interface exists but using a webinterface is really one step back. Jens
David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach?
That might well lead to zillion Trac tickets to triage. It might make sense to use a policy similar to subversion's: 1. Post to list 2. If somebody agrees it looks like a bug, and nobody jumps and immediately fixes it, enter to Trac - Volodya
Vladimir Prus wrote:
David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach?
That might well lead to zillion Trac tickets to triage. It might make sense to use a policy similar to subversion's:
1. Post to list 2. If somebody agrees it looks like a bug, and nobody jumps and immediately fixes it, enter to Trac
That sounds better to me, because bugs posted to the list often get fixed a lot faster. But I'd modify it slightly: 1. Post to list. 2. If it doesn't get fixed immediately, and no one points out it isn't really a bug, create a Trac bug report. -- Beman
Beman Dawes wrote:
Vladimir Prus wrote:
David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach? That might well lead to zillion Trac tickets to triage. It might make sense to use a policy similar to subversion's:
1. Post to list 2. If somebody agrees it looks like a bug, and nobody jumps and immediately fixes it, enter to Trac
That sounds better to me, because bugs posted to the list often get fixed a lot faster. But I'd modify it slightly:
1. Post to list. 2. If it doesn't get fixed immediately, and no one points out it isn't really a bug, create a Trac bug report.
Are errors in documentation considered bugs ?
Edward Diener wrote:
Beman Dawes wrote:
Vladimir Prus wrote:
David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach? That might well lead to zillion Trac tickets to triage. It might make sense to use a policy similar to subversion's:
1. Post to list 2. If somebody agrees it looks like a bug, and nobody jumps and immediately fixes it, enter to Trac That sounds better to me, because bugs posted to the list often get fixed a lot faster. But I'd modify it slightly:
1. Post to list. 2. If it doesn't get fixed immediately, and no one points out it isn't really a bug, create a Trac bug report.
Are errors in documentation considered bugs ?
Yes. At least that's my opinion. The severity of documentation errors ranges from unimportant to critical, so the priority of doc bugs ranges from low to high accordingly. --Beman
on Sat Nov 03 2007, Edward Diener <eldiener-AT-tropicsoft.com> wrote:
Beman Dawes wrote:
Vladimir Prus wrote:
David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach? That might well lead to zillion Trac tickets to triage. It might make sense to use a policy similar to subversion's:
1. Post to list 2. If somebody agrees it looks like a bug, and nobody jumps and immediately fixes it, enter to Trac
That sounds better to me, because bugs posted to the list often get fixed a lot faster. But I'd modify it slightly:
1. Post to list. 2. If it doesn't get fixed immediately, and no one points out it isn't really a bug, create a Trac bug report.
Are errors in documentation considered bugs ?
Yes -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Sat Nov 03 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Vladimir Prus wrote:
David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach?
That might well lead to zillion Trac tickets to triage. It might make sense to use a policy similar to subversion's:
1. Post to list 2. If somebody agrees it looks like a bug, and nobody jumps and immediately fixes it, enter to Trac
That sounds better to me, because bugs posted to the list often get fixed a lot faster. But I'd modify it slightly:
1. Post to list. 2. If it doesn't get fixed immediately, and no one points out it isn't really a bug, create a Trac bug report.
Here's my problem with Volodya's suggestion: I work with a lot of open-source software and I find lots of problems. The policy subversion uses is draconian (I recently went through it) and makes people pay in great inconvenience to report bugs in the subversion codebase. I was annoyed enough to feel as though reporting svn bugs is probably not worth my time. Here's my problem with Beman's suggestion: If I find a bug, I don't have time to keep it on my radar screen. I need to get it reported. It's highly likely that if I post about it to a list (which, incidentally, I may have to subscribe to) and don't see a reply in the first hour or so, I'm going to lose track of it. I'd much rather have issues go directly into Trac and get closed quickly than that they get lost. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Sat Nov 03 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Vladimir Prus wrote:
David Abrahams wrote:
http://boost.org/more/bugs.htm still says that the preferred way to report bugs is to send an email message. Do we really mean that? It's way more reliable to open a Trac ticket. Is there any reason not to change the "preferred" approach? That might well lead to zillion Trac tickets to triage. It might make sense to use a policy similar to subversion's:
1. Post to list 2. If somebody agrees it looks like a bug, and nobody jumps and immediately fixes it, enter to Trac That sounds better to me, because bugs posted to the list often get fixed a lot faster. But I'd modify it slightly:
1. Post to list. 2. If it doesn't get fixed immediately, and no one points out it isn't really a bug, create a Trac bug report.
Here's my problem with Volodya's suggestion: I work with a lot of open-source software and I find lots of problems. The policy subversion uses is draconian (I recently went through it) and makes people pay in great inconvenience to report bugs in the subversion codebase. I was annoyed enough to feel as though reporting svn bugs is probably not worth my time.
Here's my problem with Beman's suggestion: If I find a bug, I don't have time to keep it on my radar screen. I need to get it reported. It's highly likely that if I post about it to a list (which, incidentally, I may have to subscribe to) and don't see a reply in the first hour or so, I'm going to lose track of it.
Good point.
I'd much rather have issues go directly into Trac and get closed quickly than that they get lost.
Sometimes I get an email when a Trac bug report is for one of my libraries, sometimes I don't. I'm not sure if that's a problem with Trac or with an over aggressive spam filter at my email provider. Not sure what the best policy is. Trac seems best for those who don't follow the list closely. --Beman
on Sun Nov 04 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
I'd much rather have issues go directly into Trac and get closed quickly than that they get lost.
Sometimes I get an email when a Trac bug report is for one of my libraries, sometimes I don't. I'm not sure if that's a problem with Trac or with an over aggressive spam filter at my email provider.
If the bug's component field is not set to a library for which you're listed as the owner, you won't get email.
Not sure what the best policy is. Trac seems best for those who don't follow the list closely.
And most of our *users* don't. Those of us who are active contributors know how to get stuff done. People who run into the recommendation about how to report bugs are most likely not subscribed to boost-devel, and asking them to subscribe just makes it harder for us to find out when something goes wrong. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
on Mon Nov 05 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
on Sun Nov 04 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
I'd much rather have issues go directly into Trac and get closed quickly than that they get lost.
Sometimes I get an email when a Trac bug report is for one of my libraries, sometimes I don't. I'm not sure if that's a problem with Trac or with an over aggressive spam filter at my email provider.
If the bug's component field is not set to a library for which you're listed as the owner, you won't get email.
Not sure what the best policy is. Trac seems best for those who don't follow the list closely.
And most of our *users* don't. Those of us who are active contributors know how to get stuff done. People who run into the recommendation about how to report bugs are most likely not subscribed to boost-devel, and asking them to subscribe just makes it harder for us to find out when something goes wrong.
Discussion seems to have died down without anyone expressing a passionate opinion other than me, so unless someone pipes up soon I'm going to change that page to recommend filing Trac tickets. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Discussion seems to have died down without anyone expressing a passionate opinion other than me, so unless someone pipes up soon I'm going to change that page to recommend filing Trac tickets.
The feature request page is also worth looking at: http://www.boost.org/more/requesting_new_features.htm I'm actually in the process of moving both pages to the new site so I'll be removing them soon. But I'll leave these two up for now, in case there are any changes that can't wait for it. Daniel
on Thu Nov 08 2007, Daniel James <daniel_james-AT-fmail.co.uk> wrote:
David Abrahams wrote:
Discussion seems to have died down without anyone expressing a passionate opinion other than me, so unless someone pipes up soon I'm going to change that page to recommend filing Trac tickets.
The feature request page is also worth looking at:
http://www.boost.org/more/requesting_new_features.htm
I'm actually in the process of moving both pages to the new site so I'll be removing them soon. But I'll leave these two up for now, in case there are any changes that can't wait for it.
Sorry, Daniel, this left me a little confused about how to proceed. Why don't you move the pages to the new site, and let me know when that's done. Then I can edit them there. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Sorry, Daniel, this left me a little confused about how to proceed. Why don't you move the pages to the new site, and let me know when that's done. Then I can edit them there.
OK, I've moved them. They are at: http://beta.boost.org/support/bugs.html http://beta.boost.org/community/requests.html The guide to updating the new site is at: http://beta.boost.org/development/website_updating.html Daniel
on Thu Nov 08 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
Discussion seems to have died down without anyone expressing a passionate opinion other than me, so unless someone pipes up soon I'm going to change that page to recommend filing Trac tickets.
Done, finally! http://svn.boost.org/trac/boost/browser/website/public_html/beta/support/bug... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (6)
-
Beman Dawes -
Daniel James -
David Abrahams -
Edward Diener -
Jens Seidel -
Vladimir Prus