Will's Miro dev blog

I updated my AMD64 machine to Hardy today and built a set of Miro 1.2.3 packages for Hardy AMD64. Going forward, I’ll continue to build packages for Gutsy and Hardy for both i386 and AMD64 platforms.

Miro 1.2.3 is the last release I’ll be doing packages for Dapper and Feisty.

If someone could help out by maintaining and testing packages for those two platforms and any others that we don’t cover, that’d be really great. Let me know in the comments, by email, or on IRC.

GStreamer has a lot of momentum behind it now and a lot of work has gone into it over the last year and it’s really paying off. As such, Miro 1.5 (the next version) will be the first version of Miro which defaults to the GStreamer renderer instead of the xine renderer. I’m excited about this change and in the future we’ll be able to drop support for xine which is one less complexity to deal with.

If you’re using the GStreamer renderer in Miro with either trunk or Miro 1.2.3 and discover any problems, let me know. It helps to write up a bug, but if you’re loathe to do that, comment here. Make sure you test with totem-gstreamer or some other GStreamer movie player as well and report those results–that helps us determine whether the problem lies with Miro or possibly elsewhere.

There are probably going to be a few rough edges in the switch and I could use any help I can get with them.

Miro 1.2.3 was supposed to be a minor bug-fix release which also had xulrunner 1.9 support for gtkx11. But then vlc 0.8.6f came out and we updated our Windows build to use that. But then we found a bunch of problems and many of those got fixed. But then I decided I might as well tackle support for YouTube’s mp4 versions. But then… but then… but then… two weeks and a lot of work from a lot of people later and we finally got Miro 1.2.3 out the door.

This is the first release I’ve built Ubuntu Hardy packages for. That’s cool–a lot of work went into that.

This is the last release I’ll be building Ubuntu Dapper and Feisty packages for. If there are still Dapper and Feisty users out there (and I’m sure there are), hopefully a champion will arise from your midst and set up a PPA to support you.

I really want to thank Markus, Uwe, Janet, Ben, Chris, Luc, Paul, Dean, Sedat, all the other people who hang out on #miro-hackers, the bug reporters, the testers, the translators and everyone else involved in the last three weeks of work flurry that resulted in Miro 1.2.3.

Having said that, there were a bunch of bugs that were discovered and triaged to the next release. I wasn’t able to get a Fedora 9 virtual machine working in VirtualBox and wasn’t able to help them out with their Miro packaging problems. I also wasn’t able to spend time with my Debian Lenny virtual machine and help Uwe with his packaging.

In summary, there was a lot of stuff that was done which is great and a bunch of stuff left on the floor until the next version which is a bummer.

Onwards to the next release….

Did a release of Miro 1.2.3 rc0 today. This fixes some problems with Miro on Windows, adds xulrunner 1.9 support for gtkx11, works on Hardy (with Hardy packages, too), fixes a problem with external torrents disappearing, and other things as well. I also did another translation sync today, so it’s got the most up-to-date translations available.

The release candidate is available at http://pculture.org/nightlies/.

Hardy packages available in our Hardy repository. Details at http://getmiro.com/download/ubuntu.php.

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.

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

It was an exciting week:

• Bought a new laptop (Dell 1420n with Ubuntu Gutsy on it, 4 GB of memory and BRIGHT YELLOW)
• Spent a couple of days switching to the new laptop and getting VNC working on my desktop machine
• Worked on bugs 9614, 9627 and 3067–9627 took me a while to figure out
• Centralized the list of projects for internships, GSOC, et al — see it at https://develop.participatoryculture.org/trac/democracy/wiki/CommunityProjects
• Toyed with Hardy Heron alpha 5 for a few hours to get a feel for where we are with that; turns out Miro 1.1.2 is in the Hardy repositories, so that’s a good sign

This coming week I’m planning to:

• Work on 1.2 bugs starting with mine and continuing with Nassar’s
• Take a look at the two-stage problem with the subscribe.getmiro.com site

I want to send HUGE thank yous to the following people:

• mutantmonkey for the patch which disables the x screensaver for GTKX11 when watching movies in fullscreen — this is awesome!
• Njaal for the patch so that Miro will automatically stop seeding torrents when a specified ratio is reached in bug 8793
• Sid for the excellent bug report for 9627
• elmargol for help with bug 9614
• Uwe from Debian and Christopher from Ubuntu for the work they’re doing and the help they give us on packaging

Also, I’d like to apologize for posting my last status so late. I back-dated it, so it probably showed up on the planet pretty low.

I installed Hardy Heron alpha 5 in a VM and Miro doesn’t compile on it. Amongst other things, Hardy uses Firefox 3, so it’s likely we’ll have to make some code changes to account for that. I only spent 20 minutes with Hardy and Miro to see where things are at–no clue how much work is going to be involved.

I’d love to get someone(s) to help with working out the issues with Miro on Hardy before Hardy releases. If you’re interested in helping, leave a comment here, send me an email, or find me on IRC.

If no one helps out, then I’ll probably deal with supporting Hardy after Hardy is released.

It was a pretty slow week.

• I spent some time trying to implement 5403 and 8619 on Mac OSX, but then discovered that Luc must use some gui builder tool that I don’t have. So I ended up passing those two bugs off to him.
• I spent some time doing bug triage.
• I fixed a few problems from code flux.
• I worked on 9521 for a few days. It’s a lot more complicated than I thought it was partially because it touches sections of the code I haven’t touched yet. Nassar thinks it’s probably not something we want to bother with. I think I might be able to implement it, but I think it’ll take a week to get it right. I think we should defer it to a future version.

Things I’m planning on doing this week:

• Possibly continue working on 9521 depending on the call.
• The two-stage installer bug is still out there and I have access to pcf3 now, so I think I can solve it. I sent an email to plans regarding that subscribe.getmiro.com site being all kinds of bit-rotty and whether I should spend time fixing it, but didn’t get any replies.
• We got a patch for bug 8793 for implementing ratio restrictions for torrents for GTKX11. The bulk of the patch is the glade code for GTKX11; the actual code is pretty trivial. I’d like to look into this and probably apply it.
• Check out Miro on Ubuntu Hardy (which is in alpha 4 now) and get a feel for where it’s at.

This actually covers two weeks of work because I was in Florida for a bit in between.

Things I did:

• implemented 5403 and 8619 for GTKX11 and Windows
• worked on Mediabar specs (briefly)
• went to the Worcester office to hang out with the Nicks
• bought a Mac mini for Boston devs
• wrote a blog entry about the Firefox 3 work I did so it’s clearer as to what I was working on and how it impacts Miro
• did a 1.1.2 release which contains the exception text for OpenSSL and GPL co-existence (though it’s not entirely clear if I did this right)
• did some bug-fixing on GTKX11 to get the timebar and video information displaying correctly
• did some re-working of the theme I’m using on my devblog so it’s less annoying–still needs some help, though

Things I’m working on this week:

• finishing up work on bugs 5403 and 8619 (though I may end up giving up–I’m not really following where oid comes from in the strings)
• go through the bugs and do some more light triage work and start marking bugs that look bite-sized as such