[Sugar-devel] Notes on triage meeting
Simon Schampijer
simon at schampijer.de
Fri Feb 13 09:47:53 EST 2009
Greg Dekoenigsberg wrote:
>
> On Fri, 13 Feb 2009, Simon Schampijer wrote:
>
>> Greg Dekoenigsberg wrote:
>>> erikos ran an awesome meeting. My notes on what I think the purpose
>>> should be:
>>>
>>> First Goal. To go through all UNCONFIRMED bug reports and determine:
>>>
>>> * whether the bug report is a dupe. if so, close as Duplicate.
>>>
>>> * whether the bug report is missing key info. if so, ask questions
>>> in bug and set status to Needinfo.
>>>
>>> * whether the bug is from a previous release and has already been
>>> fixed. if so, close as Obsolete.
>>>
>>> * whether the bug is relatively minor. if so, set to block next
>>> release (right now 0.86) and set status to "new".
>>>
>>> * whether the bug is urgent. if so, set to block current release
>>> (right now 0.84) and set status to "new".
>>>
>>> Every bug should fit into one of these categories.
>>>
>>> How does that sound? Simple enough to get a good triage team off and
>>> running?
>>>
>>> --g
>>
>> Actually I would leave setting the milestone by the triage team out. I
>> think this is the duty of the maintainer. He knows better the
>> resources available. If the severity is a blocker - of course he will
>> set it to 0.84 likely anyhow.
>>
>> Objections, thoughts?
>> Simon
>
> My thought as the sort-of-guy-who-sort-of-runs-engineering-meetings is
> that I don't want to see any triaged bugs, ever, without a targeted
> release. Why? Because I want to be able to look at "current release"
> and know which bugs are out there.
Yeah true.
> Now, how do we set milestones? If we can get developers to reliably go
> clean up after triagers and assign milestons to all bugs that are in
> such-and-such state, that's ok, I guess. If we're all in a meeting
> together, it's quite easy -- I just ask on IRC. But it makes async
> triaging a bit trickier.
>
> --g
Hmm. For example if a triager puts the bug in 0.86 but for the
maintainer it would have been important to fix...
Dunno, I have to think about it for a moment I guess.
Simon
More information about the Sugar-devel
mailing list