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