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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
