On Fri, Mar 30, 2012 at 2:46 AM, Vincent Hennebert <[email protected]>wrote:
> 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 agree that there appears to have been no policy to follow through on bug transitions after reaching resolved state. I'm suggesting that we attempt to agree on a policy and implement it, and I'm suggesting that we should transition every bug to closed state. If some devs prefer not to do this (e.g., because they don't see any need to do so), I would be happy to perform the final steps as a service for the group. > 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. > Ideally we would have sufficient resources to perform a separate verification and review process for each resolved bug, after which the bug is formally closed. However, we do not in have these resources, so that is probably a more likely explanation for the current state of the FOP buglist. I would suggest it is better to arbitrary close resolved bugs even if a verification step has not been performed. This will be apparent from the bug's history information, so it would be easy enough to go back and find bugs that actually did go through the verified state. > Are you trying to get a list of bugs that have been fixed since 1.0 was > released? Actually, it was fairly easy to do this by qualifying a search for RESOLVED+FIXED with a condition that STATUS changed after 2010-07-20. The search link I provided in my original posting above contained that condition. > 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. > OK, that's a possibility. > 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. > Actually, I very much want to clean up and triage our bug list. The task I'm discussing now is just a first, and more innocuous step in this process. > 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. Understood. However, in the long term, I wonder if it is a good idea to maintain two databases of changes. DRY. As an analogy, isn't this one of the reasons that the use of @author is discouraged: because that information is captured in SVN. In any case, I'm not suggesting we eliminate status.xml, at least not any time soon. Ideally, every status entry would make a reference to a bug #. Most do (at least those changes since FOP1.0 release), but some do not. For example, there a few "bug fix" entries that do not reference a bug #. I expect this is because a committer noticed a bug and fixed it without entering a bugzilla bug. I realize this takes a few more steps, but it would be better for tracking purposes if *every* status entry referred to a bug #. > > 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. > True. > > 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. > I understand you don't see a significant benefit at present; however, I see sufficient benefit to do so, so if you don't mind, i'll go ahead and do the closes for you and others that decline. Regards, G.
