Bug#552395: 'moreinfo' should be cleared when receiving mail from submitter

2009-10-25 Thread Ben Hutchings
On Sun, 2009-10-25 at 17:26 -0700, Don Armstrong wrote:
[...]
> In cases like this, the proposal which I've been stewing over in my
> mind to allow for sorting bugs by action item is the appropriate
> thing. Basically, bugs which have a patch, bugs which have unanswered
> correspondence, bugs which have no correspondence from the maintainer,
> etc. are all examples of action item bugs, which should be presented
> to the maintainer before other bugs which aren't as pressing. [The
> precise details and everything still needs to be fleshed out, so
> everything that I just said is my current fuzzy thinking, not a
> statement of how it will actually work.]

I think a feature like that would be be very useful and might well
obsolete 'moreinfo'.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett


signature.asc
Description: This is a digitally signed message part


Bug#552395: 'moreinfo' should be cleared when receiving mail from submitter

2009-10-25 Thread Don Armstrong
On Sun, 25 Oct 2009, Ben Hutchings wrote:
> On Sun, 2009-10-25 at 16:07 -0700, Don Armstrong wrote:
> > There's no way for the BTS to know if the information received
> > from the submitter is actually the more info needed. [And
> > sometimes, it's not even information that the submitter can
> > submit.]
> 
> Of course, but a maintainer at least needs to look at the report and
> decide that.

Right.

> > In theory at least, the maintainer should respond when the
> > submitter sends in new information telling the submitter that
> > their new information is what was required, and clearing the tag
> > in the same step.
> 
> This is fine for a single maintainer, but in the case of a team-
> maintained package with a lot of bugs going to a mailing list
> there's a significant risk that they are not dealt with straight
> away and this is missed.

In cases like this, the proposal which I've been stewing over in my
mind to allow for sorting bugs by action item is the appropriate
thing. Basically, bugs which have a patch, bugs which have unanswered
correspondence, bugs which have no correspondence from the maintainer,
etc. are all examples of action item bugs, which should be presented
to the maintainer before other bugs which aren't as pressing. [The
precise details and everything still needs to be fleshed out, so
everything that I just said is my current fuzzy thinking, not a
statement of how it will actually work.]


Don Armstrong

-- 
I have no use for "before and after" pictures.
I can't remember starting, and I'm never done.
 -- a softer world #221
http://www.asofterworld.com/index.php?id=221

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#552395: 'moreinfo' should be cleared when receiving mail from submitter

2009-10-25 Thread Ben Hutchings
On Sun, 2009-10-25 at 16:07 -0700, Don Armstrong wrote:
> tag 552395 wontfix
> thanks
> 
> On Sun, 25 Oct 2009, Ben Hutchings wrote:
> > It's useful to be able to exclude bugs tagged 'moreinfo' from bug
> > triage.  However, the tag then needs to be cleared when additional
> > information is received, and it would be helpful for the BTS to do so
> > automatically.
> 
> There's no way for the BTS to know if the information received from
> the submitter is actually the more info needed. [And sometimes, it's
> not even information that the submitter can submit.]

Of course, but a maintainer at least needs to look at the report and
decide that.

> In theory at least, the maintainer should respond when the submitter
> sends in new information telling the submitter that their new
> information is what was required, and clearing the tag in the same
> step.

This is fine for a single maintainer, but in the case of a team-
maintained package with a lot of bugs going to a mailing list there's a
significant risk that they are not dealt with straight away and this is
missed.

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett


signature.asc
Description: This is a digitally signed message part


Bug#552395: 'moreinfo' should be cleared when receiving mail from submitter

2009-10-25 Thread Don Armstrong
tag 552395 wontfix
thanks

On Sun, 25 Oct 2009, Ben Hutchings wrote:
> It's useful to be able to exclude bugs tagged 'moreinfo' from bug
> triage.  However, the tag then needs to be cleared when additional
> information is received, and it would be helpful for the BTS to do so
> automatically.

There's no way for the BTS to know if the information received from
the submitter is actually the more info needed. [And sometimes, it's
not even information that the submitter can submit.]

In theory at least, the maintainer should respond when the submitter
sends in new information telling the submitter that their new
information is what was required, and clearing the tag in the same
step.


Don Armstrong

-- 
If everything seems to be going well, you have obviously overlooked
something.
 -- Steven Wright

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#552395: 'moreinfo' should be cleared when receiving mail from submitter

2009-10-25 Thread Ben Hutchings
Package: bugs.debian.org
Severity: wishlist

It's useful to be able to exclude bugs tagged 'moreinfo' from bug
triage.  However, the tag then needs to be cleared when additional
information is received, and it would be helpful for the BTS to do so
automatically.

Ben.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.31-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org