Will’s Miro dev blog

Just as a word of warning, if all goes well, Ben will be merging into trunk what he and others have been working on over the last few months in the next day or so. When that happens, trunk will become very broken and will remain that way for possibly a week as folks work on stabilizing the new user interface code and reimplementing a bunch of features… silly things like being able to play videos.

If you’re tracking trunk or using nightlies, you should seriously consider waiting a week to update.

You might ask, “Gah! What a bunch of idiots! Why are they doing this?!” The answer is that the widget overhaul is very badly needed and it’ll fix one of several big performance issues that Miro currently has. It’s a big change and it’ll cause a big mess for a short while, but it’s going to make a big big big difference.

In order to do this quickly, we’ll be focusing pretty hard on getting trunk working again for a while. My apologies if any of us seem like we’re dropping off the face of the earth or ignoring questions, concerns, …

We’ve had a few people contributing patches for the Miro codebase. I decided it was time to add a review flag like Mozilla has in their Bugzilla instance. This makes it easier for us to keep track of attachments that are waiting on reviews.

As such, I added a “review” flag to our Bugzilla instance for attachments.

I thought I’d talk a little bit about contributing patches.

Guess what? You’re a happy Miro user except for one little thing that really annoys you. You head on up to the Miro Bugzilla bug-tracker to see if this is a bug/feature that someone else has reported already. Wow–turns out it has been reported. Not only that, but there’s been some analysis done and some speculation as to a good attack vector for fixing the problem.

So you roll up your sleeves, add a comment on the bug stating you’re going to work on it, set yourself as “assigned”, dust off your favorite editor, skim through the Miro development wiki for the svn repository information and build instructions, and get to work.

A few hours later you’ve got it working on your machine. You run:

svn diff > bugid.patch

to generate a .patch file containing the changes you’ve made.

You visit the bug in the Miro Bugzilla bug-tracker, find the bug you were working on, and click on “add attachment”. You’ll see the following screen:

Deftly, you upload the patch, click on the “patch” checkbox, select “?” from the Review flag dropdown and type in will.guaraldi@pculture.org in the Requestee box.

Then you press the “submit” button!

Will (that’s me) gets an email stating that there’s an attachment waiting for review. I add it to my queue of things to look into. If it’s not something I know anything about, I’ll find someone else who can look at it. Then someone will add a comment to the bug reviewing the patch and … the rest is iterations on that.

If you’re interested in helping out, we’ve been tagging bugs that we think are good for people new to the codebase as “bitesized”. You can see a list of them here.

I live in Somerville, MA, USA and I’d like to organize a Miro hackfest in or near Boston. Possible topics for that hackfest include:

• cleaning up and improving the gtkx11 platform interface, gstreamer/xine use, …
• working on bitesized bugs and working on unittests
• hacking together an interface for Elisa or MythTV
• testing out the fledgling Mozilla embedded API with the gtkx11 interface
• sorting out packaging issues
• other things?

I was thinking we’d do the hackfest sometime in June. Possibly as part of FUDCon10 or in the vicinity.

If you’re interested and/or have ideas, find me on IRC, email me, comment below, or send me telepathic messages of hope.

I’m hoping to do a Miro 1.2.3 release in the next 7 days or so. This release will include support for xulrunner 1.9 on gtkx11, support for Ubuntu Hardy, updated translations, vlc 0.8.6f, and a bunch of bug fixes for bugs found in Miro 1.2.2 and previous releases including some more “Miro crashes on startup” type issues.

There are three things you can do to help:

1. help with translating Miro into languages you know — see https://translations.launchpad.net/democracy/trunk/+pots/democracyplayer
2. testing Hardy packages — see http://getmiro.com/download/ubuntu.php for the repository
3. send encouraging words and positive energy

Also, we’ll definitely need help testing the Miro 1.2.3 rc0 build which will be out in a few days–hopefully before Thursday.

I’ll be on #miro-hackers on irc.freenode.net. Also, if you have problems, submit a bug report at bugzilla.pculture.org or find someone to do it for you on #miro or the forums.

I uploaded a new .pot to Launchpad just now (first time for me!).

If you’re a translator for the Miro application, please take a look at the languages you translate for and update them accordingly.

We’re planning to do a Miro 1.2.3 release in a week or so. The changes since Miro 1.2 are minimal, so this allows existing translations to improve for the 1.2.3 release.

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.

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.

A little under two weeks ago patches for bugs 303645, 400061 and 400064 landed in the Firefox trunk. These patches add video/audio podcast-related enhancements to the upcoming Firefox 3. Firefox 3’s feed preview page now distinguishes video and audio podcast feeds from “regular feeds”. It will also show all enclosures in the feed with information about the enclosure.

It’s really exciting for these features to be in Firefox 3. These enhancements reduce the interface divide between Firefox and video/audio podcast consuming applications like Miro, iTunes and others. Amongst other things, it’s hugely beneficial to Miro users who use Firefox.

Here’s what the feed preview page looks like in Firefox 2 on Ubuntu Gutsy:

Here’s what the feed preview page will look like in Firefox 3 on Ubuntu Gutsy:

I’m really excited that this is going in. At a bare minimum, it means I have to spend a lot less time fishing through view source finding enclosures.

This is my first contribution to Firefox and my first time working with Mozilla developers and other Firefox contributors. There was a lot of material to come up to speed on including build process, testing procedures, who’s in charge of what, getting reviews done, …

I want to give a shout out to Mike Beltzner who was really patient and incredibly helpful in getting the functionality landed. Also to Robert Sayre and Myk Melez who reviewed the code and suggested changes and fixes that made it much better. Also to Alex Faaborg who kicked off this mini-project back in October. And lastly all the people on #developers on IRC who helped me with issues I was having: Ventnor, biese, bz, gavin, Pike, _FrnchFrgg_ and others–Thank you all!

It was neat in that the patches landed just before the beta 3 codefreeze on my birthday. Having said that, there were a bunch of problems with the patches, many of which were sorted out and fixed by other people. Sorry about that–crappy organization on my part.

I also want to point out that this is a huge advantage that open source has over non-open source: I, as a person external to the project, can still participate in a meaningful way and help implement the functionality that matters to me. That’s very empowering.

Sidenote: That show is What You Ought To Know. It’s a fun show–worth subscribing to.