Miro 1.2.3 released

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

Hardy tips for resolution fixing when using it in a VirtualBox vm

I'm trying to get Ubuntu Hardy support for Miro. I installed Hardy Beta 1 in a virtual machine with VirtualBox. The install went fine. I had problems fixing the resolution, though.

Hardy starts off with an 800x600 resolution which is too small to run Miro. To fix it, you have to:

  • run sudo displayconfig-gtk from a terminal

  • click on the dropdown for models and choose LCD Panel 1024x768

  • click on the Test button to make sure it works

  • click on the OK button to apply that one change

  • log off

  • log on again

DON'T change the monitor AND the resolution of the screen at the same time. If you do that, you see no errors, no changes get made, and you'll spend a while scratching your head wondering what happened.

If all went well, you should see the resolution you were looking for.

Note that since Ubuntu Hardy is beta software, this could all change tomorrow.

Update:

4/19/2008: It looks like they took displayconfig-gtk out of the menus in the Hardy release candidate so I updated the instructions above.

Miro 1.2.3 rc0 released!

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.

Miro 1.2.3 plans, hardy support, bug fixes, et al

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.

call for translations for upcoming Miro 1.2.3

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.

user interface overhaul, u3, hardy support

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.

what's in trunk?

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.

bitesized

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.

gtkx11 platform and xulrunner 1.9 status

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.

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
  • "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.