Open Stack

On Sat, 2013-04-13 at 23:48 -0700, Jesus M. Gonzalez-Barahona wrote:
> On Tue, 2013-04-09 at 18:42 -0700, Vishvananda Ishaya wrote:
> > On Apr 9, 2013, at 3:02 PM, Daniel Izquierdo <dizquierdo at bitergia.com> wrote:
> > 
> > > Hi Vish,
> > > 
> > > On 04/09/2013 05:47 PM, Vishvananda Ishaya wrote:
> > >> Any insight into how the number of closed tickets were generated? I
> > just checked my stats for grizzly and noticed that I fixed 38 bugs in
> > nova alone[1]. Counting all projects (it is a little harder to find
> > results for the python-*clients since we don't have coordinated
> > releases) it is somewhere around 45, yet our company only has 34
> > listed for the entire release. There is clearly some error in the
> > tickect closing statistics.
> > > 
> > > We already had a small discussion with other OpenStack members about
> > how to measure activity. What we're measuring when talking about
> > tickets are those whose final stage is "Fix Committed".
> > > 
> > > At the beginning, we considered other stages as "final" ones such as
> > "Fix Released" or "Won't Fix", however Thierry appeared to have an
> > incredible high number of "closed" tickets for that definition. So,
> > what you can see (as specified in [1]) is the number of closed bugs
> > with the condition of being in the "Fix Committed" stage (only that).
> > 
> > The act of "closing" as in changing the state of the bug is relatively
> > meaningless. Jenkins sets fix committed is most cases and the release
> > manager or jenkins sets fix released. It makes a lot more sense to use
> > the assignee of the bug. That is the person that did the actual work.
> 
> Thanks a lot for this insight. We've been playing a bit with our
> database, and these are the results [long message].
> 
> We have focused on tickets reaching the state of "Fixed Committed", as
> Mark McLoughlin and Michael Still sugeested.
> 
> First of all, there is the issue of which tickets to consider. We have
> considered tickets being closed during the Grizzly release cycle, and
> for all OpenStack trackers (complete list of what we're considering as
> "all trackers" is in http://bugs.launchpad.net/openstack. As you will
> see, numbers below are different from those commented by Mark, I wonder
> if this is because either the list of trackers or the date condition is
> different for his study.
> 
> Anyway, we've found 2,806 tickets transitioning to "Fix committed" at
> least once during the periodm with a total of 3,784 transitions of that
> kind.
> 
> Of those, we have tracked the asignee at the time of the transitioning,
> finding 387 different identities, which according to our records
> correspond to 329 different persons. Of those, we have identified
> companies for 228, which amount for 2,084

[Oooops. I was preparing the message when I noticed we had more recent
data. But the message went away anway still unfinished, sorry about
that. Numbers below (and a question for those of you interested in all
this)]

1. Number of (unique) tickets changed to Fix Committed during the 
release: 2802

- 1.a 2090 of them have been done by people associated to a company,
according to our records (remember, we can have more than a transition
per ticket)

- 1.b The person who "closes" the issue and the assignee is different in
most cases: 2683 (as you said in your previous messages)


2. How many assignee-when-fixed-commit do we have?

- assignees 388, where unique assignees (once identities are merged into
persons): 330


3. How many unique assignee-when-fixed-commit are associated to a
company?

- 229 ( 229 out of 330 unique_assignees)


4. Number of transitions to fix-committed: 3776

4.A. Number of transitions to fix-committed where the assignee is 
associated to a company: 2806 (2806 out of 3776)

4.B. By company

name;total
"Red Hat";758
Rackspace;261
IBM;239
Nebula;214
HP;192
VMware;139
Canonical;131
Intel;131
Microsoft;84
eNovance;72
NTT;64
DreamHost;54
SolidFire;49

4.C. By people - company

name,user_id,name,total
"Gary Kotton",garyk,"Red Hat",160
"Mark McLoughlin",markmc,"Red Hat",144
"Vish Ishaya",vishvananda,Nebula,128
"Zhongyue Luo",zyluo,Intel,90
"Alessandro Pilotti",alexpilotti,Microsoft,84
"Aaron Rosen",arosen,VMware,83
"Dan Prince",dan-prince,"Red Hat",73
"Chuck Short",zulcss,Canonical,68
"Steven Hardy",shardy,"Red Hat",62
"Russell Bryant",russellb,"Red Hat",58
"Dolph Mathews",dolph,Rackspace,56
"Julien Danjou",jdanjou,eNovance,50

For those of you interested, I can share the SQL queries we're using,
and the last version of the database (which we have still not uploaded
to the website).

In addition, we're tracking time-to-close for tickets, and there the
difference between committed and released matters, because times are
different. When do you think a ticket should be considered as closed? At
"Fix committed" or at "Fix released" time?

Right now, the condition for considering a ticket as closed is:

new_value = 'Fix Released' or new_value = 'Invalid' or new_value =
'Expired' or new_value = 'Won\'t Fix'

Do you find this ok? Any other state?

Saludos,

	Jesus.

-- 
-- 
Bitergia: http://bitergia.com http://blog.bitergia.com