[openstack-dev] Grizzly's out - let the numbers begin...
Jesus M. Gonzalez-Barahona
jgb at bitergia.com
Sun Apr 14 07:37:28 UTC 2013
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. 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 ) 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
> 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
1. Number of (unique) tickets changed to Fix Committed during the
- 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
- 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
3. How many unique assignee-when-fixed-commit are associated to a
- 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
4.C. By people - company
"Gary Kotton",garyk,"Red Hat",160
"Mark McLoughlin",markmc,"Red Hat",144
"Dan Prince",dan-prince,"Red Hat",73
"Steven Hardy",shardy,"Red Hat",62
"Russell Bryant",russellb,"Red Hat",58
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?
Bitergia: http://bitergia.com http://blog.bitergia.com
More information about the OpenStack-dev