Potential BTS improvements
I'm not quite sure what list I should be posting this to. There doesn't
seem to be a list specifically for discussion about the bug tracking
system (though there are plenty of operational bts lists).
As I understand it, we're about to see an upgrade to the bug tracking
system where closing a bug would be associated with a package version.
This is a good thing.
Here's some other possible improvements:
[1] Allow bug reporters to become "active users". An active user would
periodically receive automated messages about the status of their bug
report, and we would be required to respond in a timely fashion or would
drop them regular user status on that bug. [If the user wants to submit
a public key, that can be used as their identity -- otherwise their
identity is simply their email address, and without a public key, we
should require round-trip confirmation on any information from that user.]
This would allow us to say: if a bug report was introduced by an active
user, then that bug report can only be closed by that user.
To offset problems this might introduce, bugs which are tagged
unreproducible would NOT be considered release critical unless a large
number of active users had reported the bug*. The size of this number
would be a judgement call on the part of the release manager.
* because bugs can be merged, it's possible to have more than one person
who reported the same bug. If this becomes a significant issue we might
want to streamline this aspect of bug reporting. The important point,
however, is distinguishing between "can't reproduce because of user error"
and "real bug which can't be reproduced for some other reason".
We might need to introduce some additional tags to indicate that a bug
is believed to have been fixed and that we're waiting on confirmation.
[2] Instead of simply opening and closing a bug, we should track which
releases the bug appeared in, and which releases it's fixed in. Some of
this is already supported in a sort of optional fashion (with tags).
A lot of this can be automated (we know which package version has the fix,
and can know which releases the package version appears in).
It should be possible to orphan/nmu a package for a specific release,
once a fix has appeared for some other release. [This is different
orphaning the package entirely -- it's a statement on the part of the
package maintainer that the release in question won't be supported.]
Notes:
The active user concept is somewhat influenced by what I read at
http://www.joelonsoftware.com/articles/fog0000000029.html
All of the above fits under the "We won't hide problems" aspect of
our social contract -- but there are a lot of critical details I've
skimmed over.
Comments?
Thanks,
--
Raul
Reply to: