Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sudha.ponnaganti@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Sudha Ponnaganti <sudha.ponnaganti@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Wed, 24 Oct 2012 14:17:51 -0700
Subject: RE: [DISCUSS] Bugs: How do we close + handle bugs?
Thread-Topic: [DISCUSS] Bugs: How do we close + handle bugs?
Thread-Index: Ac2yKElsSI3Sl8oiS3GXmtL8iiH6OAAAWetA
Message-ID: 
 <7914B38A4445B34AA16EB9F1352942F1012F10C2DFBC@SJCPMAILBOX01.citrite.net>
References: 
 <1351111406.18175.140661145023041.6B922EA5@webmail.messagingengine.com>
In-Reply-To: 
 <1351111406.18175.140661145023041.6B922EA5@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Open defect Triage:
During 4.0 release cycle, I saw some community members (mainly release mana=
gers) are assigning defects and I myself also triaged and assigned some def=
ects based on priority and impact. Triage can be done when release is plann=
ed for 4.1 so community can decide which defects are must fix for 4.1. I wo=
uld think P1 and P2 are must fix and no triage might be needed and can be a=
ssigned to members who are working in certain area - rest can be looked at =
to see which are required for 4.1 and which can be deferred. Other way to d=
o is publish this filtered list and ask  community members to pick and rema=
ining ones can be looked at by release manager and others who would like to=
 triage defects. =20

Defect closure:
Whoever requested or opened the defect can close the defect and if there ar=
e others that remain can be closed by whoever is validating the feature. Th=
is can be done during release cycles pretty easily I would think.  A little=
 bit of triage is needed but if reports are being sent regularly and consis=
tently, community would take action to bring down the resolved defect numbe=
rs.  During 4.0 release cycle around 30% defects are left in resolved statu=
s i.e not validated even though fix has been done. Out of those 30% defects=
 some could be rejected and that is the risk associated leaving them in res=
olved status.=20

As we grow towards automation, defect closure can be achieved through execu=
tion pass rates. But we are far away from that at this point.=20

I would like to participate in triage process if there is a need for it.=20

Thanks
/Sudha

-----Original Message-----
From: Joe Brockmeier [mailto:jzb@zonker.net]=20
Sent: Wednesday, October 24, 2012 1:43 PM
To: CloudStack Developers
Subject: [DISCUSS] Bugs: How do we close + handle bugs?

Hey all,=20

During today's IRC meeting, the topic of bugs + bug closure came up.
Specifically, the question of whether we should have any set procedure for =
handling bugs and closing them.

Right now, when I see a bug that I can fix, I assign it to myself and then =
update the bug once I've submitted a patch/fix and then Resolve the issue -=
 but I do not close out the bug. Instead, I leave it to the submitter to ve=
rify that the bug is fixed and let them close the bug.
Other folks do it differently.

The question I have is whether we want to have a standard procedure for han=
dling bugs? Should the person submitting a patch also be the person to clos=
e a bug?=20

Should we have some form of triage for bugs? We currently have 126 open bug=
s (out of 411 opened so far) and 71 of those are unassigned. How do we ensu=
re someone is looking at those?=20

Thoughts?

Joe
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/