Will's blog

purpose: Will Kahn-Greene's blog of Miro, PyBlosxom, Python, GNU/Linux, random content, PyBlosxom, Miro, and other projects mixed in there ad hoc, half-baked, and with a twist of lemon

[ home | blog home | recent activity ]

Fri, 21 Mar 2008

some numbers I drummed up while building Ubuntu packages....

After that lunch on Wednesday where I talked about how much I really love the numbers and pretty graphs that are on planet.mozilla.org regularly, I wanted to do stats on Miro.

There are two things I'm interested in measuring. The first is measurements related to release cycles and development process. The second is measurements related to contributions.

Anyhow, here are some rough tables: 

           tag      tv/    released    cycle
           ------   -----  ----------  -------
Miro 1.0   151 MB   53 MB  11/13/2007  N/A
Miro 1.1   169 MB   58 MB  1/10/2008   58 days
Miro 1.2   253 MB   63 MB  3/20/2008   70 days
We're still doing tight release cycles. I'm hoping we'll trend towards longer release cycles. Something in the 3 month range would be easier on the devs and probably other people, too. 
           bugs fixed all gtk mac win    bugs created all gtk mac win
           ---------- --- --- --- ---    ------------ --- --- --- ---
Miro 1.0   65         18  17  15  15     85           20  17  17  31
Miro 1.1   40         16  6   10  8      106          44  21  20  21
Miro 1.2   82         26  14  13  29     --
I'll let you interpret the data as you like. I think the "bugs fixed" column is indicative of our priorities between the releases: 1.0 was a stability-focused release, 1.1 put out libtorrent, and 1.2 involved a code overhaul which caused a lot of regressions. 
          languages
          ---------
Miro 1.0  63
Miro 1.1  66
Miro 1.2  70
I'd like to figure out how to get a rough measure of quality of translations, but I'm not really sure how to go about doing that. I threw together a script to count the number of instances where msgid differs from msgstr, but the results don't seem very indicative of a correctness or completeness figure. Launchpad has statistics, but there's no way to look "back in time" at previous releases that I can find. Are there any ideas for how to do that by looking at the .po files? 
          patches from contributors applied
          ---------------------------------
Miro 1.0  4
Miro 1.1  2
Miro 1.2  1
What this table shows is that almost all development is being done by PCF. This table troubles me the most--more about that at the end. On to stats from Bugzilla.... First off, our Bugzilla data before October is probably mediocre, so I'm not really even looking at that. After that, the data has been getting better as more people are helping to triage and annotate bugs. Also, some bugs never make it to Bugzilla. I know that sedatg and some other people mention issues to us on IRC semi-regularly which get fixed, but aren't tied back to Bugzilla bugs. It's probably fair to say these stats are indicative of things but aren't 100% accurate. 
Miro 1.2 stats
==============
length of cycle:      70 days
bugs fixed:           82 total
  By Operating System:
     all:             26
     gtkx11:          14
     osx:             13
     win:             29

  By Severity:
     blocker:          1
     critical:        12
     major:            5
     normal:          58
     minor:            2
     enhancement:      4

  By Component:
     Channels         11
     Download          4
     Feeds             1
     Guides            3
     Install           5
     Library - New     3
     Menu - Shortcut   3
     Min - Max         1
     Playback         14
     Playlists         2
     Search            6
     Startup          10
     Storage           1
     System settings   2
     User interface    5
     main             11

bug reporters:        24 total
     pcf people:       7
     community:       17
Miro is benefiting greatly from the community with testing and translations--that's really great and it's helping a ton! However, Miro is not getting much help from the community with code and PCF is pretty much funding all development. This is troubling. Miro is getting bigger over time and the complexity is growing, too. There are a lot of moving pieces in the stack of external components that Miro relies upon. There are two ways for Miro development to scale well:
  1. more contributors
  2. additional funding for PCF so that they can fund developers
If you can contribute code, please let me know if there's something blocking your path. If you can't contribute code and/or you're interested in Miro getting better, then install iHeartMiro (there are versions for Firefox and IE) and/or donate money and help PCF fund developers.

[ tags: miro | category: /miro | Permalink | View/Add Comments: 2 ]

Comments:

Posted by Per Thulin on Fri Mar 28 14:49:48 2008
> If you can contribute code, please let me know if there’s something blocking your path. I sympathise with Miros goals and I'm a programmer so I could get involved with the coding. However I (from a Linux perspective) don't really see how Miro is fitting in between MythTV, Elisa, Banshee, Entertainer, Amarok, Totem, Rhythmbox and the other multimedia systems out there. Was a new project really necessary? What I'm trying to say is that it doesn't feel so compelling to contribute to a project where there's a lot of overlap from other open source projects.


Posted by wguaraldi on Fri Mar 28 15:27:06 2008
The crux of the question is two fold: 1) Is it better to have many projects in the same application domain or is it better for all of us to pool our resources on one or two? 2) Why should Miro be a separate project and not fold into one of the many other projects in the same application domain? The first one is a philosophical question. If you're a programmer that works on or follows Free Software development, then you've probably witnessed this sort of question on many mailing lists, blogs, articles, ... No sense in rehashing it here. Personally, I'm a fan of diversity. The second one is mission-related. Our mission is really different from the missions of any of the listed applications and probably any of the other applications in our application domain. The mission is really important. For us, it's our driving force and reason to exist. Are there ways for us to accomplish our mission without building a whole new application? Possibly. However, Miro was started years ago when many of the projects you've mentioned were in similar nascent stages. Some of them didn't exist. So in regards to this specific list at the time PCF started working on Miro, it's not clear that was a good option. Even if you're not a fan of diversity, Miro uses a lot of components that some of the other media players you mentioned are using. The work that we do that affects those components affects other projects using those components and vice-versa--that's a good thing. If there was only one project using gstreamer, it wouldn't have flourished the way it has over the last couple of years. At some point, I'd like to get an XML-RPC interface going so that Elisa and MythTV can use Miro as a subscription/download component. There are other ways Miro could be working with other projects, too.


Post a new comment:

Three things:

  1. New comments get placed in a "draft" status and will NOT show up on the site until I explicitly approve it. Sometimes that happens within 24 hours.
  2. I reserve the right to reject/remove inappropriate comments.
  3. Sometimes I'll reply to a comment directly in email--so make sure your email address is correct.

If you can't for some reason post a comment, send me an email: willg at bluesock dot org.

Your name:


Your e-mail address (this doesn't get displayed to anyone--sometimes I'll reply directly to you):


URL of your website (optional):


Comment:


Yes, I am a human!

pyblosxom::1.5-dev git-master

Copyright 1996 to 2012, Will Guaraldi Kahn-Greene, under the Creative Commons BY-SA 3.0 license

Creative Commons License
Will's Blog by William Kahn-Greene is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.