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 <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
