On 28/03/12 17:39, Glenn Adams wrote: <snip/> > If we did have a full QA process, we would assign resolved bugs to someone > to check and transition to verified state. Then one of the following would > be designated to transition the bug to closed state: (1) original > submitter, (2) fixer, (3) QA, or (4) PM. > > Leaving a bug in resolved state (according to the fixer's perspective) does > not close the loop on the bug (at least in my opinion). In fact, it remains > an open bug as far as bugzilla is concerned, e.g., closed bugs are > displayed in strike-out style, while resolved bugs are not. > > The reason I am raising this now is because I am reviewing the bug list > since the FOP 1.0 release in order to prepare information for a possible > upcoming FOP 1.1 release. In doing this review, I found some bugs marked as > resolved+fixed and others as closed+fixed. This makes it more difficult to > compile and classify the status of bugs, and results in inconsistent views > about the status of given bugs or FOP as a whole.
The number of closed fixed bugs (54) is negligible compared to resolved fixed (908). I’d say that in our project, this is the closed fixed status that’s abnormal... I still don’t see what it brings you to close bugs? If we ‘automatically’ close them after 2 weeks have passed like you suggest below, then they wouldn’t be any more ‘verified’ than bugs that are simply ‘resolved’. ‘Verified’ implies that someone took out some steps to check that the bug was actually fixed, which wouldn’t be the case if it’s arbitrarily closed. Are you trying to get a list of bugs that have been fixed since 1.0 was released? Given that no attention is being paid to the ‘Version’ field, I don’t know how you can get that. Plus we may well have fixed bugs that were created at the time of 0.95, and not updated to include 1.0 after it was released, and if the bug was still present. We can decide to be more diligent in managing our bugs database, but we would have to clean it up first, and given the number of open issues, that would be /a lot/ of work. In the meantime, we have a status.xml file at the root of the project that lists the issues that have been resolved, and that are worth mentioning in a release announcement. In my experience, this status.xml file is fairly well maintained, and can safely be relied upon. Much more safely than our Bugzilla, at any rate. > I would prefer that we attempt to take the effort to allow the original > submitter to comment upon resolved+fix bugs and close the bug, and, if > after some time has passed (e.g., 2 weeks) without the submitter doing > this, then the fixer (or any committer) may close. One reason to do this is > that the original submitter may not agree that the fix actually fixes the > problem they reported. In which case they tend to react fairly quickly, and re-open the bug anyway. Sometimes (most of the time?) the original reporter is no longer involved, so it doesn’t really matter any more whether the bug has been fixed for them or not. > If you or another committer prefers not to take the extra steps of closing > bugs you have fixed, then I would be happy to close them out so you don't > need to bother with it. Please let me know if you would like me to do this > for you. If I’m convinced that closing bugs brings us some benefit, I will certainly do it. ATM though, I still don’t see the interest. So yes, I’d be grateful if you could do that for me for the moment. Thanks, Vincent
