[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How to Triage: Draft posted on wiki

Christopher Beland wrote:
(Regarding https://fedoraproject.org/wiki/User:Beland/How_to_Triage )

On Wed, 2009-03-18 at 13:26 -0700, Adam Williamson wrote:
I'm not sure it's a good idea for the triager to do the work of
splitting a report which actually deals with multiple issues up into
separate reports. The problem is that then the triager becomes the
'reporter', and it won't be clear to the maintainer that the real
reporter is actually some guy on the CC list. This could lead to
confusion. I'd prefer to put the onus on the reporter to split the
issues up.

I was wondering whether cloning a bug would maintain the reporter?  If

Is "clone" like "fork?" Do you want two (or more) threads of discussion.

An alternative to my previous suggestion might be a subordinate bug, "this also occurs in ...." The parent bug cannot be closed (the software won't allow it) until all subordinate bugs are fixed too.

It might be that a bug report reflecting on F10 might be prompted to a parent, that points to F10 and any where else it occurrs. The F10 subordinate bug could then be closed.

Discussion should be against the parent, and the original reporter should be kept informed of progress.

not, then it's probably best for the reporter to file a new bug, unless
the triager can reproduce the problem.

Er, the reporter has a problem in F10. Isn't it expecting a bit much of a reporter to install and test on RHEL[1] xx, Rawhide and anything else you can think of?

An _experienced_ triager could take a punt that "This might occur in ...."

1. yes, I know _this_ is Fedora. I can't help thinking RHEL matters too, because the bugs database is shared/



-- spambait
1aaaaaaa coco merseine nu  Z1aaaaaaa coco merseine nu
-- Advice

You cannot reply off-list:-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]