Re: On maintainers not responding to bugs
On Mon, Feb 26, 2007, cobaco (aka Bart Cornelis) wrote:
> no we can't, as an example I had a bugrapport (with patch) open on
> desktop-base for over a year, no reply. It came up in discussion at
> debian-desktop list and turns out the maintainer list had somehow gotten
> unsubscribed from the package bugs, and the maintainer simply hadn't seen
> the bug.
Indeed; and in the end, most of your patch was reused for a different
implementation! Thanks. :)
You have some very nice ideas which happen to exist in some upstream
bug trackers:
> I've seen your bug report, at first glance fixing it seems to have lower
> priority then A, B, and C on my TODO-list.
=> priority field on bug reports exists in bugzilla, mantis, scarab,
jira... and might be helpful in our BTS as well!
I'm not sure the maintainer would bother writing an actual message each
time he sets a priority, but perhaps we should also send messages to
the submitter when some attributes of the bug report change (title,
severity, priority, ...); most upstream trackers do this, but they have
per-user preferences, so one can also turn off these messages or filter
what one wants to read ... or not.
> 1) you don't want to leave people hanging (as an exercise in understanding
> the users point of view pretend it's an ftpmaster or other central
> project function that isn't showing any visible reaction to whatever
> information/action request you send)
So, about this problem, most other bug trackers have a workflow with
bug /states/, for example: unconfirmed => new => fixed => confirmed
We do have some support of the "confirmed to exist" concept with the
"confirmed" tag; I suppose the confirmed tag would be enough to encode
the fact that the bug has been seen and is confirmed to be a real bug,
but it might be more useful (as above) if changes of the confirmed tag
would trigger an email to the submitter.
--
Loïc Minier <lool@dooz.org>
Reply to: