Apache OpenOffice (AOO) Bugzilla – Issue 10522
[RFE] allow to change the owner of RESOLVED FIXED bugs
Last modified: 2017-05-20 09:42:44 UTC
according to http://www.openoffice.org/issues/bug_status.html, bugs which are RESOLVED need to be sent to QA for verification. However, once an issue is RESOLVED, it seems that it cannot be re-assigned. This implies that owner of the bug needs to inform the QA-engineer which is to verify the bug by mail, by cc, or whatever. This is somewhat ... unhandy. Of course this problem would not occur if the one who resolves the bug set's the owner at the same time, but this has disadvantages: - it can be forgotten :) - it means that the resolver loses the issue from her radar. The issue-life-cyle document is not very clear about this, but I think that the owner should only be changed if the resolver has verified the bug herself in a real build, not only in the private development build. (Well, at least this is how we @ Sun handle this for years). So the life cycle which seems to make much sense is: * check in the fix, RESOLVE the bug as FIXED * wait for the next independend build, verify the fix, and change the owner to the QA engineer * the QAE VERIFIES the fix in the public build, too This could be easily reached by the simple change :) of allowing to change the owner of a RESOLVED bug ....
reassigning to support.
This can be addressed by asking the QA contact (via the comments field) to check the "next independant build" has been verified, while not changing the status of, the issue. This will send emails to the owner, all on the cc list and the QA contact. This does not alter the ownership of the item but it may serve the purpose. Upon testing the QA engineer can choose to verify the resolution or re-open. Will this suffice? I suggest the previous option mainly becuase we are not doing any "enhancement/feature" work on IZ now due to the soon-to-be-released new issue tracking system.
Brian, thanks for the feedback. I think your suggestion would not really solve the issue, because the time between the request for verification and the actual verification may be long enough to produce a lot of wrong statistics - finally, the status is expected to reflect what needs to be done about an issue, and if a issue is started, but contains a "fixed in real, QA please verify" comment in the description, it does not fullfill this criterion. However, if this brand new issue tracking system is to arrive in this galaxy anytime this year :), I would be fine with resolving as LATER - it's not really really really urgent (though I am pretty sure that it is a one-liner :).
back to support
Frank - I'm not sure what statistics you are referring to when you mention because of a time lag in verification. So I cannot really address that concern. As to the status of an issue not reflecting its actual condition, IZ is setup to provide for that. A status of "resolved" only confirms the claim that there is a resolution to the issue. Once in that state the issue still needs to be set as "verified" by another party, presumably qa, and yet a third party (if so desired) can be responsible for another sanity check and "close" the issue. This seems to provide for accurate statuses according to the issue's condition. No? Finally, our new Issue Tracking software is already being tested on a few sites and will be ready for general deployment soon. So, it is up to you if would like to resolve with a status of "later". I don't have an actual date for you on the new software. You would have to talk to the OOo folks (Stefan or Martin) as I think they have been apprised as to the Collab roadmap. Bonus footage - If you would like to submit a patch to IZ, feel free. ;) Also, if you are curious the new issue tracker open-source project is available at http://scarab.tigris.org/.
> I'm not sure what statistics you are referring to ... Statistics which count the number of currently RESOLVED, VERIFIED, STARTED, UNCONFIRMED, aso bugs, on a per-owner basis. This is a valid, though sometimes overstressed :), approach to get an impression where we are with a product. > As to the status of an issue not reflecting its actual condition, IZ > is setup to provide for that. A status of "resolved" only confirms > the claim that there is a resolution to the issue. Yes, but the ownership is important, too. Provided that I checked in a fix just a second ago, I can then * - RESOLVE the issue as FIXED - verify myself in the next build/release - ask (in the description) the responsible QA engineer to VERIFY or * - RESOLVE the issue as FIXED - wait until the next build/release, verify myself - REOPEN the issue (!this is the step I would like to omit!) - assign it to the QA engineer, asking hin/her to VERIFY or * - leave the state STARTED - wait for the next build/release and verify myself - assign the issue to the QA engineer, asking him/her to VERIFY - ask the QA engineer to VERIFY (I understood that this was your original suggestion, but I may be wrong) In only the second process, the following three states, reflecting actual reality, exist: - RESOLVED FIXED, and owned by the developer - <something>, and owned by the QA engineer - VERIFIED, and owned by the QA engineer In the other processes (and in all other processes I can imagine - am I missing something? :), there are states which to not properly reflect the real state of the issue and/or the person who is the next to take action on the issue. In the second, process, the additional step of REOPENING the issue - is annoying - resets the state to NEW, which, speaking strictly, is not correct - it's still FIXED. Maybe "NEW FIXED" would be appropriate. Thus, saving this REOPEN step, and allowing to reassign a bug which is RESOLVED FIXED to the next person who needs to do something about it, would solve this issue here :). > So, it is up to you if would like to resolve with a status of > "later" No, sorry. Either you (@collab.net) say that it's a valid request, then please you RESOLVE it - as LATER, if scarab will allow such a workflow, or as FIXED, if you will implement it in IZ :))). If you don't think that the RFE is valid, then _you_ please RESOLVE this as INVALID. It's you decision @collab.net, not mine. > Bonus footage - If you would like to submit a patch to IZ, feel > free. ;) Oh well, this is nothing I am capable of doing - much to less C++, for my taste :). > Also, if you are curious the new issue tracker open-source project > is available at http://scarab.tigris.org/ will have a look, thanks
Thanks for the feedback, Frank. The capability exists in the new issue tracker software. So, closing with a status of later.
seems to be fixed with CEE 3.5.1.