Hi Thomas, thanks for the massive work you're doing in the tracker.
On November 24, 2010 02:44:22 pm T. Modes wrote: > Status: > Triaged <-> Confirmed > Triaged: when I read status report? > Confirmed: only when I can reproduce the bug? I would suggest: Triaged: we know it is there and we may still need to analyze things on our side (as opposed to Incomplete when we still need input from the reporter). Examples: - a power user reads the new ticket. He determines that it affects nona only and tag it accordingly, but he can't estimate how much effort it is to fix, or if it is fixable. - a developer reads the new ticket. He determines that only Windows is affected and tag it accordingly, but he is not a Windows-dev and can't determine what needs to be done. Confirmed: the report is complete and the next steps are obvious, we just did not get there yet. Examples: - a user reported a wish to set output format and compression as a preference. a power user has determined that this is indeed a valid feature request, tagged it as hugin preferences and set it status triaged and priority wishlist. A developer decided he wants to tackle this sooner or later, so he sets the status to confirmed and assigns it to himself. - a user reported that hugin crashes on a certain operation. another user reproduced and confirmed. a power user reproduced and confirmed and set it to status confirmed, leaving priority undecided. Triaged means: we know it is there but there is still work to do on the ticket. Confirmed means: we know what work there is to do in the code. > But what is when nobody else can reproduce the bug or informations are > missing (in latter case incomplete?) two different cases. informations are missing: post a comment specifying the information missing and set to incomplete (obvious). difficult to reproduce: less obvious. use your judgment. If enough people have tried to reproduce unsuccessfully, set to won't fix (I would have preferred a "work for me"). Some of the nastiest bugs are the spurious / difficult to reproduce ones. Maybe at some point in the future somebody can reproduce it with more debugging info and at that point the previous "won't" fix report may come handy. Although, I don't think any reports (including the expired ones) is deleted from the system. they are just hidden. > Fix commited <-> Fix released > Only bugs with status fix released does not appear in the default > list. > What's the prefered way: Using normally "Fix commited", "Fix release" > only after official release, but this would requiere a second change > to the bug? For now (first run over a massive amount of bugs) I would say use "Fix released" and forget the finer grained approach. Later on (I would say: after 2010.4) it will be useful to distinguish between Fix committed and Fix released to give feedback to the user why they still see the bug and you claim it is fixed: because they are using a release and the fix is in the bleeding edge. I am not sure that a second change to the bug is required. I am still setting up the milestones, and then tickets can be pinned against milestones. I would expect that when I "close" the milestone with a release, it will automatically set the status from committed to released. We'll get a chance to test this during the 2010.4 release cycle. > How do we use the status? here is a first draft proposal, feel free to improve http://wiki.panotools.org/Hugin_Trackers#Understanding_Ticket_Status Yuv
signature.asc
Description: This is a digitally signed message part.
