[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-tm-dev] Re: Committers: Bug Verifications
|
Sounds good to me.
_______________________
David Dykstal
david_dykstal@xxxxxxxxxx
"Oberhuber,
Martin"
<Martin.Oberhuber To
@windriver.com> "David McKnight"
<dmcknigh@xxxxxxxxxx>, David
05/19/2006 08:04 Dykstal/Rochester/IBM@IBMUS,
AM "Kushal Munir" <kmunir@xxxxxxxxxx>,
"Michael Berger"
<mjberger@xxxxxxxxxx>
cc
"Target Management developer
discussions"
<dsdp-tm-dev@xxxxxxxxxxx>
Subject
Committers: Bug Verifications
Dear Committers,
as we've been fixing lots of bugs recently, the question came up when and
how we'd want to verify them.
I propose the following strategy:
You can set a bug RESOLVED/FIXED in Bugzilla whenever you think
something is fixed. You don't need to go to great length verifying
the fix. Just use good judgement about the fix actually working.
When a bug is set RESOLVED, the reporter will get an E-Mail
notification automatically. The reporter is free to verify the fix
immediately if he wants. If he does so, he can set the state to
VERIFIED.
When we are getting close to our release (in August or September),
we'll reserve some extra time for verifying all fixed issues against
the release candidates. That is, we'll be going through all bugs that
have state FIXED or VERIFIED, and set them to CLOSED if they actually
work.
So this proposal means, that setting a bug VERIFIED is an "unofficial" note
from the submitter that the fix actually works.
Setting a bug CLOSED is the "official" note that it actually works in the
release.
The VERIFIED state will help us during the official verification stage when
we are setting the bugs CLOSED. For bugs which are VERIFIED already, we'll
take less time and resources for actually back-checking checking the fix
than for RESOLVED bugs.
Comments regarding this?
Cheers,
Martin
--
Martin Oberhuber - WindRiver, Austria
+43(662)457915-85
