How to Triage: Draft posted on wiki
debian at herakles.homelinux.org
Mon Mar 23 13:51:10 UTC 2009
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 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/
1aaaaaaa at coco.merseine.nu Z1aaaaaaa at coco.merseine.nu
You cannot reply off-list:-)
More information about the test