Will’s Miro dev blog

What landed in trunk recently?

• (r6564, bug 9692) initial round of hardy support — this is ongoing; help is more than welcome
• (r6637) u3 support for the windows-xul platform
• (lots of revisions) user interface overhaul — this covers a lot of revisions and is ongoing work

Am I missing anything? Let me know in the comments.

I’m starting a new category of my devblog where I’ll mention what’s just landed in trunk. This does two things:

1. it forces me to keep track of what’s landing in trunk
2. it’s an easier to digest view of things than Trac timeline of svn
3. it’ll let people know what’s in the pipe
4. it gives people who are tracking trunk a vague idea of stability levels

I’ll start blogging interesting things landing in trunk with their revision numbers and probably break it down into bug fixes, enhancements, and misc stuff.

Any thoughts, suggestions, et al–toss them in the comments.

If you’re eager to help Miro with code contributions, but don’t know where to start, take a look at bugs marked with the bitesized keyword in Bugzilla.

You can see a list of them here.

I merged the changes into the Miro-1.2 branch and cut a tarball. You can get the tarball at http://pculture.org/nightlies/Miro-1.2.2-test.tar.gz.

This code needs testing from distributions that are only using xulrunner 1.9. It “works for me” with Ubuntu Hardy Beta 1 today (but didn’t work yesterday) and it works with Ubuntu Gutsy (where it compiles against Firefox). I haven’t tested it on other distributions.

For the most part, I fixed things that were obvious compile/runtime issues. I didn’t delve into the API differences between xulrunner 1.8 and 1.9 and fix deprecation problems and things of that nature. The changes I made are mediocre, but they seem to work for me. They’re loosely based on changes in the Ubuntu packages. I talked about that in a previous blog entry.

I need help testing this with other distributions. I also need help making sure that no other changes are required. Reply in the comments below, toss a comment in bug 9692, ping me on IRC, and/or send me an email to my pculture.org email address.

The more help and the more eyes we get, the more likely that the code will work where you need it to work.

If no one helps out, then I’ll probably just release it and see what happens.

Note: The changes in the above linked tarball are NOT in the Miro 1.2 or 1.2.1 releases. This is not a final release. This is for testing purposes only.

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

• “tag” - size in MB of the codebase which includes binary kits and other
  stuff
• “tv/” - size in MB of just the tv/ directory
• “released” - release date
• “cycle” - the length in days of the release cycle

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     --

• bugs fixed - number of bugs fixed and then broken down by platform
• bugs created - number of bugs created against this version and then
  broken down by platform

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.

Twenty minutes ago or so we released Miro 1.2. I was talking to Chris, Bryan, and John about Miro 1.2 yesterday at lunch (mid-release) because while there was a lot of work done on Miro 1.2, not a whole lot of it is immediately obvious to the typical Miro user. That got me thinking about writing a post that better explains what did happen and why it’s important.

The Miro 1.2 release post has a list of things we worked on for Miro 1.2. Most of that list consists of things we did in a week or so. The majority of the release cycle work hours were spent on two items: switching to xulrunner 1.9 on Windows and re-architecting to further separate the “frontend” from the “backend”. I want to talk a bit about those two items and why they’re important.

Let’s start with the xulrunner 1.9 change. Firefox 3 is based on xulrunner 1.9. Switching to xulrunner 1.9 even though it’s not released yet was important because the Mozilla crew have done awesome work on improving performance in their current release cycle. Many of the performance improvements are memory-related. It definitely doesn’t make Miro the most optimized thing ever, but it helps. Additionally, Nassar (who did the work) spent some time refactoring bits to make sure events were happening in the correct thread of execution and reducing some of the layers of abstraction and indirection involved. This work will make Miro on Windows more stable than it was previously.

The re-architecture work that Ben did is also really important. Previous versions of Miro had a backend and frontend that were tied together. Creating new platforms was arduous and it hampered any efforts towards building a daemonized platform or a platform that talked to MythTV or Elisa…. He made the split between the two much cleaner and at the end wrote a sample command line interface. In the process of doing that work, he did a bunch of other things that affected the entire code base: he fixed the namespace issues we had with Miro Python modules and he did some refactoring.

This opens up a lot of possibilities. It will be easier to write a daemon Miro platform that has an XMLRPC interface. It will be easier to write a slimmed down version of Miro for smaller computers like the Nokia n810. It’s a good direction to be heading in.

I continued working on getting Miro 1.2 released. One thing we need to do better is coordinate translations. I’ll be working on fixing that part of the release process for the next release cycle.

I also worked on getting Miro trunk to compile and work with xulrunner 1.9 and on Ubuntu Hardy. I finished this today and checked it in. It seems ok, but definitely needs peer review from someone who’s more familiar with XPCOM.

I had a cup of coffee with Nathan from Creative Commons. He was out here doing work somewhere at MIT and I live nearby so we got together. For Miro 1.0, he implemented license extraction from RSS feeds. You can see the end result of this when you see the “license” item in the feed item details. When the publisher has license information in the feed, this links to the license. When you watch video content on the Internet, think about what roles you play in that content… Are you merely a passive consumer? Can you take the content and remix it into new content with new meaning? Can you share it with your friends? Can you post it elsewhere? The license information answers these questions and more. Thank you Nathan!

He and I talked about other areas where Miro and Creative Commons intersect and then we talked about PyBlosxom–another project I work on.

Once Miro 1.2 is out, I’m going to go back to work on Mediabar. I’ll probably be working on that for the next week or two.

Our current status for translations is pretty rough. We support a lot of languages, but few of them are complete translations. See https://translations.launchpad.net/democracy/trunk/+pots/democracyplayer/.

If you look at that page, you’ll notice most of the translations haven’t been updated and/or are missing strings. Of those translations, the only ones that are complete are English (United Kingdom), Norwegian Nynorsk, and Ukranian.

I think part of the problem is that we don’t have a good way of telling people that we need translation updates.

If you’re set up to do translation work or know someone who is, please take some time this weekend to update the translations for your language. We’re planning a Miro 1.2 release some time next week. Hundreds of thousands of people world-wide will appreciate what you’ve done.

Also, if there’s something that I can do to help make updating translations more timely, let me know.

This week I fixed some bugs, worked on some bugs that I didn’t get anywhere with, and finally tagged and released Miro 1.2 rc0.

I also did some work with getting Miro on Gutsy to compile against xulrunner 1.9 in the backports repository. I was basing the work on the set of packages the Ubuntu people maintain. There are some changes in there I don’t understand the relevance of and their changelog isn’t very helpful. I pinged Fabien, but haven’t heard anything back from him.

As a side note, and I can’t imagine I’m alone in this feeling, Windows bugs really suck and take gobs and gobs of time to work through.

This week was an ok bug-fixing week. I worked on:

• Bug 9644: implemented a preference allowing you to switch between renderers on GTKX11–it’s not great, but it’s good enough (probably).
• Bug 3067: applied a patch for suspending the screensaver when playing video in fullscreen on GTKX11… then I found a couple of problems with it and backed it out today.
• Fixed a bunch of other bugs related to gstreamer renderer, ff/rew, revver, mefeedia, …
• Worked on bug 9214 where if you click on the delete link when viewing a video in fullscreen on GTKX11, then you’re stuck in fullscreen. I worked on it for a couple of days and ended up giving up today.
• Sent out a proposed tentative release schedule for Miro 1.2 to the develop mailing list.
• Helped with some of the initial GSoC preparation.

Next week I’m going to:

• Bug 9692. Check out Fabien’s patches for Ubuntu that get Miro to work with xulrunner 1.9.
• Bug 9691. Look into Miro compiling with gcc 4.3. Uwe said something that suggested that gcc 4.3 on Debian is imminent. So… this needs to be figured out.
• Continue to shepherd Miro 1.2 until it’s out the door.

Busy busy busy….