Will's Miro dev blog

I tagged and built Miro 2.0 rc3 builds and placed them in the sticky section of the nightlies page.

Pre-release release notes are at https://develop.participatoryculture.org/trac/democracy/wiki/2.0ReleaseNotes.

Changes since rc2:

• updated translations as of today
• bug 11329: decimal value for movie duration is never correct in channel view
• bug 11327: os x crash, windows error – when selecting item (non-ascii) to share
• bug 11149: New OSX DMG Background to replace current one
• bug 11296: ‘show more’ jumps back to top of list on ‘Single Items’ and ‘New’
• bug 11322: File “miro\feedupdate.pyc”, line 67, in update_finished KeyError: 26
• bug 11262: python 2.6 support (preliminary and untested)
• bug 11317: os x – crash after added torrent feed then selecting channel tab.
• bug 11354: “Global name ‘time’ is not defined” death on laptop
• bug 11348: os -x – automatic update failure
• bug 11357: list view for new tab broken
• bug 11027: Changing default guide on windows: AttributeError: ‘NoneType’ object has no attribute ‘url’
• bug 11321: ValueError: I/O operation on closed file
• bug 6179: Wrong Language (only some work done on this one)
• bug 11360: os x r9142 – update notification is show release notes text.
• bug 11362: Dissmising detached external playback dialog freezes Miro
• OSX crashers and memory leaks
• probably some other things I’m missing

The new Miro Guide will be launching very soon now. When that’s released, the second browser bar you see in Miro will go away.

I’ve synced translations, so rc3 has the latest translations. I will sync them one more time before we do a release. If you’re a translator, we sure could use your help! See more at https://translations.launchpad.net/democracy.

We think this release candidate is release-worthy. Assuming testers don’t hit any snags, there shouldn’t be any changes between now and the final Miro 2.0 release. We’re planning to follow Miro 2.0 with a 2.0.1 release in the near future to get the most updated translations and to fix minor issues that pop up.

To Ubuntu Hardy and Intrepid users: Some day I’ll get to learning how PPA works. When that happens, we’ll start building release candidate builds for the Ubuntu versions we support. Until then, you’ll have to download the tarball and build it yourself. If someone can spare some time to help us with this, I’d be much obliged.

Barring snags with this release candidate, we’re looking at a full on Miro 2.0 release some time in the next few days. Getting really super close now!

I saw Chip’s blog entry announcing Parasite yesterday and checked it out. I had problems getting it to work with Miro, but he has since fixed the bug I was bumping into.

I think this will be a really useful tool, so I’m doing a short write up of how to use Parasite with Miro.

1. Grab Parasite from git compile and install it. Instructions are on the Parasite web-site.
2. When you run make install It’ll install libgtkparasite.so into /usr/local/lib/gtk-2.0/modules/ .
3. Launch Miro like this:

   LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib/gtk-2.0/modules/ GTK_MODULES=parasite ./run.sh
   

That’ll launch Miro with Parasite showing you the widget hierarchy and widget properties and all that.

There’s a screencast on the Parasite site that shows off more things you can do.

I checked in the latest ui in r8671. I’ve been told that a number of tweak requests are on their way, but it’s looking pretty good and there weren’t any major bugs.

The new ui took me a week and a half to implement. There were a bunch of complexities that made it difficult. I thought I’d talk about some of those here so people who aren’t as intimate with the code can get an idea of how much work and what kind of work is involved.

First off, Miro 2.0 uses native widgets instead of HTML/CSS/Javascript for everything. The one place this isn’t quite true is in the item lists where we’re rendering our own widgets using a layout/cellpacking API that abstracts over a platform-dependent implementation layer. The platform-dependent implementation layer consists of two implementations: OSX (cocoa, pyobjc, …) and GTK (pygtk, pango, …). The abstraction layer is very similar in style to the GTK side of things. Ben wrote most of this as we needed it a few months ago.

The first problem I had was that I wasn’t familiar with the platform-independent layout/cellpacking API we had.

The second is that there are a bunch of variations on the theme. Depending on what the context is, the item gets rendered differently. In playlists, items have a “Remove from playlist” button, but in channels, the item has a “delete” button.

Additionally, items have two display modes: with details and without details. The without details mode is the easiest to render since it’s just a bunch of packed things and the resizing handling is easy to deal with. The with details mode is really difficult because we want to show the entire title and description for the item but the cells these bits are in expand as the window is resized. We get into this chicken-and-egg problem where we need to lay things out, but in order to lay things out we need to know the size of the space we’re laying things out in, but in order to know the size we need to lay things out….

On top of that, items are either selected or not selected–both of which look different.

The other set of problems I ran into were theming issues. The rendering code tries to “look” like the platform it’s running on: the OSX buttons look different than the GTK buttons; OSX uses Finder but Windows uses Explorer and the text needs to reflect that; …

All of this makes for very complex implementation code. Structuring that as I figured things out was difficult to do well and the result isn’t great structure-wise. Ben’s already done a pass at fixing the resizing issues which resulted in some structure fixes. It’s likely that other things will get fixed and massaged over the next week or so.

The end result of all this work is that we went from this:

to this:

I did some bug triage today and then went through and fixed some old bug data (apologies to everyone for the bug spam). A couple of interesting things came out of that.

First off, it’s interesting to note that 2.0 so far has 163 bugs marked as FIXED. That’s more than any version of Miro since 0.9.5. Hard to know what happened before that because we have inadequate bug data. Go team!

Second, there are a total of 877 open bugs right now. 323 of those are targeted as Wishlist items. We’ve been around the 850 mark since September with a big bump between December and February in the 1000 range. I think that means generally speaking that we’re keeping up with bugs which is good.

Third, it’s pretty clear that the widget overhaul will clear out a lot of older bugs. Partially because we’re ditching the HTML interface and the issues that caused, but also because we’re re-implementing a lot of stuff and in doing that, fixing issues in the process.

Miro 2.0 is going to rock your socks!

I’m heading to OSCON 2008 and will be hanging out in the Mozilla booth talking about Miro things, Mozilla things, happy things, and whatever other things.

When I’m not hanging in the Mozilla booth, I’m hoping to be doing some Miro hacking (and possibly some PyBlosxom hacking–we shall see).

I’ll be wearing Miro and Miro-related t-shirts until I run out. Then I’ll be wearing other things.

If you’re planning to be at OSCON, stop by the Mozilla booth and talk to me about things you like, things you dislike, and favorite channels. I’m also very interested in helping people learn how to help out.

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.

I haven’t put Dapper and Feisty builds for Miro 1.1 into the repository yet. The Gutsy builds are there, but there are some issues with segfaulting when watching videos with them. I’ve only heard about Gutsy segfaulting with Miro 1.1 from one person and there aren’t any new bugs for the issue. From that I’m guessing the issue is pretty limited user-wise, but don’t really have a good way to measure.

The last few days went like this. We did a Miro 1.1 release on Thursday and I started building Ubuntu builds for Dapper, Feisty and Gutsy that afternoon using the new pbuilder-based scripts I’ve been working on. The pbuilder-based scripts are great in that I can automate building packages for Dapper, Feisty and Gutsy for i686 on a single machine (no longer need VMs) and they verify the build-depends lines in the .dsc files. That’ll make building from source possible.

The problem with Miro 1.1 is that the switch from BitTorrent code to libtorrent code causes compiling to take longer. Additionally, the pbuilder-based scripts pull down all the dependencies and build the environment to do the build in for each distribution and that takes a while, too.

When working on builds, I had problems with the Dapper and Feisty builds segfaulting when playing videos during testing. I first blamed the new build scripts. I spent 8 hours or so fiddling with them, verifying all the build steps, and eventually running them in the distribution VMs I had. On Saturday, I decided that theory wasn’t a good one.

I tried a few other things and then started bisecting the svn changes since Miro 1.0 in my Feisty VM to see if I could find the checkin that caused the problem. After a few more hours, I discovered that it was a change to xine_impl.c that I made for bug 9373 that causes the segfaults when viewing videos. Another hour later and I verified this is the same problem with the Dapper build.

I backed out that change and re-ran and re-tested everything.

In summary, the pbuilder-based scripts are fine and backing out that xine_impl.c fix fixes the issues I was seeing.

We’re working on a Miro 1.1.1 release that has some changes that allow for co-branding. We decided to push these changes off to 1.1.1 so that we could release Miro 1.1 a week earlier. I decided that I’d skip builds for Feisty and Dapper for Miro 1.1 and instead do builds when we released Miro 1.1.1 this week. That should happen in the next day or so.

I really apologize for the current situation. It was a confluence of several circumstances that led to me taking a long time to figuring out the cause of the problem which sucked.

I should have 1.1.1 builds of Gutsy, Feisty and Dapper out by Friday night if not sooner.

Other projects are publishing their Bugzilla stats, so I took 30 minutes and threw together a script to run some numbers against our Bugzilla instance.

Two things to keep in mind when looking at these numbers:

1. We migrated our bugs from Trac to Bugzilla in mid-August. Trac wasn’t working out for us and we’ve got a lot of crufty bug data still hanging around since then.
2. The numbers are slices of data. They can indicate things, but there’s a lot of context that they don’t take into account. So it’s good to be careful about drawing conclusions based solely on the numbers reported.

Stats for the year: 2007

BUG STATS
=========

Total bugs created: 4052
      41 - Miro Mediabar
       3 - getmiro.com
      35 - Broadcast Machine
    3809 - Miro
     164 - Miroguide

Bug activity:
     736 - FIXED
     170 - INVALID
      35 - WONTFIX
     139 - DUPLICATE
     169 - WORKSFORME
       0 - MOVED
       0 - NEEDSINFO

    4052 - CREATED
   13564 - COMMENTS

USER STATS
==========

Users created: 645

Top 7 bug reporters:
    3172 - Janet
     138 - Dean Jansen
     102 - Nicholas Reville
      52 - Nick Nassar
      47 - sg
      35 - Fluteman
      28 - Ben Dean-Kawamura

Top 7 bug commenters:
   10354 - Janet
     331 - Nick Nassar
     315 - Will Guaraldi
     312 - Ben Dean-Kawamura
     286 - Luc Heinrich
     259 - Dean Jansen
     217 - Paul Swartz

There are a few things I want to point out.

First, is that we’ve got 645 new Bugzilla users since mid-August. That’s really great!

Second, is that Janet is not a machine that generates 10 bugs and 30 comments every day. What’s going on is that I tied her Bugzilla userid to all the bugs I migrated from Trac for which I had no userid to tie to.

Third, sg and Fluteman are really fantastic. The work they’re doing is making a huge difference in the direction and quality of Miro. Thank you!

Thank you to everyone who’s helped out in 2007. I hope the numbers for 2008 are doubly-impressive.

Miro 1.0 has been released! Yay!

I’ve only been with PCF since July (or maybe it was June–I forget), but since I came on board we’ve been working hard on stability and honing the feature set. Working on stability is hard because there are a near infinite number of combinations of library versions, video card drivers, operating systems, … out there and all of them are slightly different. Writing software that works on multiple platforms is non-trivial. It’s a huge testament to the community of users and testers and developers that Miro is at the point it’s at now.

One thing about 1.0 that I want to mention is that this is a snapshot in time of a continually evolving piece of software. If you look at Bugzilla, there are dozens of interesting features that we’re all interested in that range from starting Miro as a daemon process to viewing video as it’s downloading.

Chris, Nick and Ben are working on post-1.0 development already. There’s been discussions on the develop mailing list regarding reworking the user interface to use native widgets and make it much faster and more responsive. Paul is continuing work on the Miro Guide. Janet is working on making community testing easier for everyone involved and produce better testing data. I’m switching off to work on Mediabar. Dean and the Team Miro folks are working on honing the documentation and they’re doing a fantastic job of testing and identifying issues for release candidates and versions.

Miro development is moving along and its momentum is a direct result of us all working towards a common goal: building an Internet video player using Open Source and open standards that will enable the current generation of media content to flourish.

One other thing I want to mention is that we ditched the conflicts between the miro package and the sun-java*-plugin packages for Gutsy and Feisty. The problem between the packages still exists and it’s intermittent, but several conversations with people caused me to rethink adding the conflicts. So this doesn’t fix anything–it’s just trading one set of problems for another, however I’ve come around to agree that the conflict is more of a pain in the ass than occasional intermittent crashes.

We released 0.9.9.9 yesterday and it took us 5 or 6 hours from tagging the branch to releasing builds. That’s pretty cool and makes for a smooth release. Also, I didn’t screw anything up this time.

I’m an employee of PCF so it’s my job to work on Miro (and the other things I work on). However, I’m just one guy and time is a limited resource. There’s no way I can triage, identify and fix all bugs. I appreciate all the help that I can get. I had a bunch of help this release.

I wanted to thank the following people for the time they spent submitting quality bugs, sending in patches, and helping me fix issues:

• Simon from dbus-python who walked me through fixing the dbus-python deprecation issue and reviewed the code changes I made.
• Markus who helped me with a variety of Gutsy and Gutsy packaging issues.
• Paul who noticed our README was out of date and suggested changes.
• Matthias who helped with Gutsy and Feisty packaging issues.
• Gotz who helped with packaging issues.
• Stéphane who helped with packaging issues.
• Marco who helped with packaging issues.

If there’s anyone else that helped out that I’ve forgotten, I apologize. Please kick me and/or comment below.

We’re well on the path to a solid 1.0. When 1.0 is finally out, we start working through the architecture changes required for many of the features that have been suggested.

I want to clarify the situation with Miro and the sun-java6-plugin package.

Prior to 0.9.9.9, if you had the sun-java6-plugin installed and you install Miro, then Miro would crash on startup. For 0.9.9.9, we added a conflict with the sun-java6-plugin package. That means that in order to install Miro, you will have to uninstall the sun-java6-plugin.

I’ve gotten a lot of flack for this fix in the last couple of days–and for good reason: this sucks for users who have that plugin installed. I definitely understand the frustration and we don’t consider this a final solution. (As a philosophical note, most development solutions are not final–most things can be changed if a better feasible option is found and implemented.)

The bottom line is that if you use the sun-java6-plugin plugin, you can’t use Miro. Adding the conflict line to the package makes it more user-friendly when installing Miro because then you’re not stuck in a situation where you have installed Miro, it crashes on startup, and you have no clue why.

We’re interested in a real solution for this problem. Details of the problem are in these bugs:

• bug 5092
• bug 8444
• bug 9064

If you have feasible ideas, add them in the comments on bug 9064 or comment here.

It’s been a wild couple of days. I finished up the rc0 release for Windows and Mac OSX on Saturday, spent Sunday upgrading my laptop from Feisty to Gutsy and then on Monday we had some quirky subversion collisions.

We’ve worked out some/most of the issues with the Ubuntu packaging for Miro and build a package for Gutsy. This package is available in the Miro repositories.

Things to note:

1. This package is release candidate 0 for version 0.9.9.9. If you are at all squeamish about testing software in a beta state, you should wait for the 0.9.9.9 final release which will be sometime this week or next week.
2. Back up your ~/.miro directory BEFORE installing and using this package. If there were issues, you want to be able to go back to your previous Miro state.
3. Miro conflicts with sun-java6-plugin. You can’t have both installed at the same time. This is a workaround for problems we’re having with the sun-java6-plugin, gtkmozembed, and Miro. If this is a problem for you, you should wait until the 0.9.9.9 final release. It’s possible we’ll have a different fix for it by then, but it’s more likely that this will happen in version 1.0 or later. If you know how to set up gtkmozembed so that it doesn’t load plugins, let us know.

Instructions:

If you follow the directions at http://www.getmiro.com/download/ubuntu.php but use:

deb http://ftp.osuosl.org/pub/pculture.org/miro/linux/repositories/ubuntu gutsy/

as the line to add, then you’ll pick up the Miro repository for Gutsy.

What to do if things don’t work:

Let us know if you have any problems. Good ways to do this would be:

• add to an existing bug report or create a new bug report in our Bugzilla system, and/or
• comment here (but make sure I have some way to reply to you)
• hop on #miro on irc.freenode.net and let us know.

And if it worked great, we’d love to know that, too.