I haven't been following along very closely, but I have an idea on something that might help out with bug management (assuming this hasn't been talked about).
I went through and marked a bunch of bugs as incomplete yesterday because it seems that pidgin was updated and their problems were resolved and the bug creator didn't come back to close their bug out. My idea is to have launchpad send out an e-mail to the bug creators of bugs relating to packages that were recently updated asking them to check with the update (provide instructions on how to update) to see if their problem is resolved, while also marking the bug reports with something like "package update check" which will expire the report if the bug creators (or subscribers) find their problems resolved and don't attempt to close their reports. In my opinion this would help close out many bugs only leaving the important ones to devs/triagers. Opinions?/Possibility?/Comments? ~Brian C. Research is what I'm doing when I don't know what I'm doing. --Wernher Von Braun "The second law of thermodynamics: If you think things are in a mess now, JUST WAIT!!" On Fri, Aug 22, 2008 at 8:56 AM, Sense Hofstede <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Scott Kitterman schreef: > > On Wed, 20 Aug 2008 18:42:01 +0100 "Caroline Ford" > > <[EMAIL PROTECTED]> wrote: > >> 2008/8/20 Alexander Sack <[EMAIL PROTECTED]>: > >> > >>> But there are also many crash reports where the retracers fail and we > >>> dont have any testcase. You want those to stay open as well? > >> But what do we do with these then? They are still bugs, and with some > >> crashes we never seem to get a backtrace with symbols. > >> > >> Currently we just close them and hope they go away.. > > > > Personally, I think closing them after some period if similar crashes > stop > > coming is reasonable. For me I think the period should be rather long > > (like most of a development cycle) unless there is reason to think > > something's actually been fixed. > > > > There are a wide range of styles project can using for managing their bug > > database. I've worked on projects that never closed bugs that they > > couldn't tie to a specific fix. I worked for another one that had a bug > > status called OTO for One Time Only. This was treated as very close to > > closed, but was actively checked for dupes. I recall another where the > > project manager routinely ordered bugs to be closed (because he'd told > > someone it was fixed) without reference to the state of the code base. > > That one did not end well. > > > > I think we have veered to far in the direction of closing bugs. It's > > almost as if someone, in homage to Emporer Joseph II in Amadeus said, > > "There are simply too many bugs". > > > > I'd probably find it more useful if bug triagers invested more time in > > trying to reproduce bugs and get them to Triaged and less of finding ones > > they might close. > > > > Scott K > > > > You've got a good point here. Our main goal should be turn as much bugs > is possible into bugs that contain enough information for the other > teams to fix them, not to close as much invalid bugs as possible. > Triaging bugs correctly is something that is good for a lot of people, > closing invalid bugs is just good for the bugsquad and people searching > the bug database. That doesn't mean it isn't important, of course. > However, I feel that our task is kind of like the assistants of the > prime-minister that prepare his state visit. They look up background > information about the destination, create a scheme and brief the > prime-minister about his visit. We too make sure all information is in > place for the fixer to start. If (s)he has to look up a lot of > information that's easy to find before (s)he can start, less bugs will > be fixed. Of course it isn't a bad thing when the fixer needs to look up > some things by himself, but I think that (s)he should at least know what > (s)he's supposed to fix. > That's why I think that making bugs good should be the main task of > a > bug triager. It's not about how much you can mark as triage, but how > good you triaged them. Marking bugs as invalid can be a good thing, but > only when it's really necessary. Specifically looking for them is a > waste of time. I don't really like the idea of marking bugs that could > be a bug invalid. When a bug has a reasonable description -- not > something like "NO SCREN! ATI What shuld I do?" -- I think it shouldn't > be marked as invalid unless the author specifically tells that it has > been fixed for him(like Scott already said). I really like the OTO > status, I think it would be good to implement it in Launchpad. > > It's not bad to have a lot of incomplete bugs. What matters is that as > much bugs as possible get fixed as quick as possible. Whether some bugs > are marked as invalid or incomplete doesn't matter there, maybe it can > even make things better since bugs would stay in-sight for a longer time. > > - -- > Sense Hofstede > <http://www.qense.nl/> > <https://launchpad.net/~qense <https://launchpad.net/%7Eqense>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIrreQxft9JZoh5JwRAjAoAKC85BmXCHjIwIieRVR1wYHN5n0TLQCgrsOj > UvlOmhjQZu6tauHq/nnqW6s= > =pOJY > -----END PGP SIGNATURE----- > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
