[Chandler-dev] Bugzilla cleanup

[Mimi Yin]

On Feb 22, 2008, at 5:40 PM, Grant Baillie wrote:

> On 22 Feb, 2008, at 16:52, Sheila Mooney wrote:
>
>> On Feb 22, 2008, at 4:35 PM, Katie Capps Parlante wrote:
>>
>>> The work queues are coming together, I believe now is the time to  
>>> do some cleanup in bugzilla. We need to make some decisions about  
>>> how we use bugzilla with the process and the new projects.
>>>
>>> *Target Milestones*
>>>
>>> The comments below apply to both desktop and web...
>>>
>>> - I assume that any bug *not* in the queue should be targeted as  
>>> "Future"
>>
>> This makes sense.
>
> Agreed. I'm not super-picky here: Basically, I'm in the mode of  
> looking at the work queue, and leaving it up to other people (you  
> and Mimi, mainly) to understand the greater cloud of Desktop bugs.  
> Along the way, I do try to respond to bug reports as they come in  
> and/or fix "obvious" problems that people run into.

Sounds good.

>
>>> - I assume that we don't want to make decisions lining up bugs  
>>> with releases in advance -- bugs get fixed in their order in the  
>>> queue and we release on a regular schedule and/or when we've  
>>> passed a major milestone in the queue
>>>
>>> - Do we want one target milestone for everything in the work  
>>> queue? Target milestones for major thresholds (like 1.0 for  
>>> desktop)? Do we want to create a target milestone for each  
>>> release and move bugs as they get fixed so that we have a record  
>>> of what release the bug was fixed on?  I don't have a strong  
>>> opinion on these questions yet -- interested to hear people's  
>>> thoughts.
>>
>> If we are just dealing with timed releases, I don't think it makes  
>> sense to move bugs over to a target milestone as they get fixed.  
>> It's just one more thing to do and it adds more targets to the  
>> list which could just confuse people. We should keep it simple and  
>> just assign the whole queue to some major milestone. It's easy to  
>> see what is in the queue and what is not (future). I am assuming  
>> you can get a checkin report that lists out what bugs were fixed  
>> so we can put that out with the release notes. I guess I don't see  
>> any advantage to having this in bugzilla. That's my 2 cents.
>
> My $0.02 is different from yours :). I have a small canned query I  
> use to detect mis-targeted fixed bugs (probably similar to what  
> Philippe used). I'm more than happy to go on reassigning them,  
> since IMO it makes generating release notes much easier.

1.0 milestone would be helpful. Help us monitor feature creep :)

Move fixed bugs to a target milestone for each release also sounds  
good. Helps us track progress.

>
>>> *Processing NEW bugs*
>>>
>>> - I'd like to avoid the "bug councils" that we had before Preview  
>>> where we discussed each bug in a rather large group.
>
> +1 :)

Yay

>
>>> - Proposal: designate one person to triage NEW bugs as they come  
>>> in. The person would be expected to send a report to the list  
>>> about the triage, and others could raise a flag on the list if  
>>> they objected to the way a bug was triaged or wanted more  
>>> conversation about it. The designated person would probably be  
>>> Mimi or Sheila.
>>
>> Sure I can do this. I will consult with others on an as needed  
>> basis since in many cases I might need some developer and/or  
>> design input.
>
> That would be great, thanks! I am feeling a little overwhelmed by  
> my Bugzilla queue, and having someone help make sure things don't  
> fall through the cracks would be most helpful.

Yea, I think Sheila would be better than I.

>
> --Grant
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev