Bug resolution for multiple issues in description

[Sergey Rudchenko]

On 08.09.2009 9:51, Niels Haase wrote:
> 2009/9/7 Sergey Rudchenko<sergey.rudchenko at gmail.com>:
>
>    
>> Is there a generic model how to process (or split) such bugreports? I
>> mean, how long such bug would live unassigned (assume the mentioned
>> problems persist). I see this as a dead-end. Only stock comment doesn't
>> move the bug to the resolution, does it?.
>>
>>      
> The correction of this behaviour should be done by the reporter of the
> bug. Split the bug and reopen from a triager might be not the best
> idea, since from now on you are the reporter and all "NEEDINFO" flags
> are opened against you in this case. But again, the "Two or more
> issues" is more the case that Reporter A opens a bug e.g X fails with
> Voodoo 3 and Reporter B ad a comment that his/her X is also falling
> bit with a Voodoo 6 Card. Same symptom, but different cards. But
> again, in this bug, it seams all related to gdm and also linked to the
> same problem.
>
>    
Ah, so I just leave that bug until EOL or the reporter will split it 
himself (then I would close this instance as a dupe of a newly reported 
one).
Maybe it's worth adding a non-stock comment about splitting advice to 
inspire the reporter.

> I guess that I need to thank you, since I like your way of triage
> bugs. (We talked last week also at irc (me is arxs there) about the
> "shut-down without warning in gdm" bug and the 'triage' keyword if you
> remember). This shows me that you really think about our triage
> efforts and not blindly click on "triaged". Again, thanks for your
> work as a volunteer of gdm triaging.
>
> PS: Hope to see you at the meeting today 15:00 UTC on IRC at
> #fedora-meeting on freenode.
>    
Thanks, I try to be pedantic :)
I'm really glad to see such a healthy community, I get much help from 
experienced members.
I would like to be present on the meeting (and on the previous), but 
unfortunately I'm on my daily job at that time.
Though I'll try to follow the meeting carefully.

--
Best regards,
Sergey Rudchenko