-----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>
-----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
