[Chandler-dev] Bugzilla cleanup

[Grant Baillie]

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.

>> - 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.

>> *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 :)

>> - 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.

--Grant