Will's blog

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• should be pushed out soon

Miro 3.1 status (roadmap)

• work is coming along nicely--probably done with development by the end of March.

Miro Community 1.0 status (roadmap)

• coming along

Luc:

• added support for running unit tests on osx
• made some other clean-ups in the mac build

Will:

• worked on Miro 3.1
• wrote an article for Gnome Journal
• continued research

Paul:

• spent some time on Miro Guide fixing bugs from django-refactor going live
• Miro Guide should be fine now for the Miro 3.0 launch
• continued working on Miro Community 1.0 stuff

Janet:

• continued working on eggplant tests for Miro
• tested other things

bugzilla

• 9 bugs/feature-requests created
• 9 bugs marked FIXED
• 1 bugs marked WORKSFORME

I'm a Miro developer employed by Participatory Culture Foundation. I wrote a post about me back in September of 2007 which covered a bit of what I do. A lot has changed since then as my role on the project has increased in scope and I've moved and various other things like that. This is an update.

What I do:

I'm involved in project management, release planning, release engineering, maintaining development infrastructure (bugzilla, git, wiki pages, documentation, build scripts, nightly builds, bogon deflector, syncing translations with Launchpad, ...), Ubuntu packaging, some testing, bug triage, user support, and I'm a liason between the Miro project and packagers and related projects.

I also do a lot of Miro development primarily on the Windows and Linux platforms. I keep track of bugs in Debian and Fedora and fix them upstream. I handle most of the incoming patches from contributors and try to help contributors where I can to make their lives easier.

I spend a ton of time on Miro work--probably between 60 and 80 hours a week.

How does telecommuting work:

I telecommute which makes it easier to work on Miro whenever I have a free moment (blessing and a curse). I work with the other Miro people through email, IRC, Bugzilla comments and weekly conference calls. We're all pretty autonomous and it works pretty well. I imagine this is in large part because we're such a small team. If the team grew, we'd have to adjust the way we do things accordingly.

Development setup:

I bought a Del 1420N with Ubuntu on it a couple of years ago and do all my development on that. I'm running a pretty stock Ubuntu Karmic with a bunch of virtual machines in Virtual Box to cover different versions of Ubuntu and Windows and also other Linux distributions. This is my primary development machine. It's yellow.

I also have:

• a Macbook running OSX 10.4 for nightly and release builds (work machine)
• an old Dell something running Windows XP for nightly and release builds (work machine)
• a Mac Mini running OSX 10.5 for OSX development (work machine)
• a Dell XPS M1210 laptop (terrible machine) for Windows testing (work machine)
• an AMD64 box I built for AMD64 builds and testing
• an ASUS EeePC 701 running Ubuntu Karmic UNR for testing on a netbook
• a circa 2002 Gateway laptop running Debian Testing for testing
• a Neuros Link (graciously donated by Neuros Technology) for testing

I'd really like to get a bigger monitor. The 1440x900 display I have now is small and cramped most of the time. I also need to build a better desk.

Ways you can get a hold of me:

irc: willkg on #miro-hackers on irc.freenode.net
email: will dot guaraldi at pculture dot org

Meet me for coffee:

I live in North Chelmsford, MA, USA. It's about 30-45 minutes from Boston. If you're in the area, I'd love to hang out for coffee. I head into Boston periodically for conferences and hanging out with family and friends. I'm definitely interested in hackfests or talking shop.

The rest of my world:

My web-site is at http://bluesock.org/~willg/. I curate Python Miro Community and Gnome Miro Community. I maintain PyBlosxom. I'm a member of the Free Software Foundation. I'm a lover, not a hater.

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• should be pushed out soon

Miro 3.1 status (roadmap)

• work is coming along nicely--probably 3 to 4 weeks of development

Miro Community 1.0 status (roadmap)

• coming along

Janet:

• working on creating eggplant test cases from litmus test cases
• 25% of them are created now

Will:

• worked on Python Miro Community and Gnome Miro Community
• made source tree layout changes to master branch for Miro 3.1
• finished up User Manual for Miro 3.0

Paul:

• moved Miro Guide to a new server--faster, fewer errors, better performance
• worked on performance fixes and bug fixes for Miro Community

Ben:

• working on Miro 3.1 stuff

bugzilla

• 14 bugs/feature-requests created
• 1 bugs marked DUPLICATE
• 3 bugs marked FIXED
• 1 bugs marked WORKSFORME
• 3 bugs marked INVALID

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• we're ready for a release. srsly.
• making builds today and pushing it out over the next few days.

Miro Community 1.0 status (roadmap)

• coming along

Will:

• finishing up the user manual
• will talk to Nick about putting manual on getmiro.com

Luc:

• worked on 10.4 super weird issues
• blind fixes seem to be working--so that's good
• talked to perian folks--they're close to a release

Paul:

• mostly worked on sysadmin things
• changed the workflow for bug handling for Miro Community which should make it easier to get fixes in faster
• working with sys admins to move Miro Guide to a new server

Ben:

• really sick last week
• triaged crash reports from 3.0 rc3
• started organizing for 3.1 stuff

Janet:

• fell off the call
• continued regression testing testing Miro 3.0
• worked on User Manual for Miro 3.0

bugzilla

• 18 bugs/feature-requests created
• 3 bugs marked DUPLICATE
• 2 bugs marked WORKSFORME
• 1 bugs marked INVALID
• 4 bugs marked FIXED

PyCon 2010 is over and the PyCon AV crew is working on taking the video they've recorded, editing it, and posting it. As they post it to the Pycon blip.tv feed, I'm pulling it into Python Miro Community. You can keep track of my status here (RSS).

I sent an email to the Cambridge Python Meetup (Cambridge, MA, USA) asking if they still record video and if so, where it gets posted.

Nate Aune sent me a link to the PloneTV feed. I'm in the process of pulling those videos in.

One thing I've noticed while curating Python Miro Community is that the quality of the image and audio make a huge difference in the usefulness of the video after the event. It's a huge project with a lot of finicky bits to reliably create great video.

Many many props to Carl Karsten, the PyCon-AV team, and all the other people out there doing this work. It allows these presentations to live beyond a moment in time and reach a much larger audience.

This is the last call for translations for Miro 3.0.

Translations are done with the Launchpad translation interface.

If you do translation work or know someone else who does, take some time today (Monday, February 22nd, 2010) to help improve the translations for Miro 3.0.

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• rc2 is going well: 150 Windows downloads, 60 OSX downloads, 30 source downloads
• there are a few bugs we're still working on, then another release candidate

Miro Community 1.0 status (roadmap)

• coming along

Janet:

• continued testing Miro 3.0

Ben:

• worked on subtitle support issues on Windows
• looking into weird crashes that Nick saw
• looking into crashes on upgrade

Will:

• worked on some bugs
• worked on the miro user manual
• worked on python and gnome miro community

Luc:

• fixed some bugs that Janet found on Monday

Paul:

• worked on Miro Community stuff over the last week
• we have two designers working on the style sheets and html
• working with Morgan on an admin system refresh
• working on moving feed updates to a separate server with a queue

bugzilla

• 24 bugs/feature-requests created
• 1 bugs marked
• 1 bugs marked DUPLICATE
• 13 bugs marked FIXED
• 1 bugs marked WONTFIX

If you're one of the lucky people going to PyCon 2010, you might want to spend some time coming up to speed on some of the talks being given.

Interested in the GIL? David Beazley is giving a talk on the inner workings of the Python GIL. He's given several GIL-related presentations before: Asynchronous vs. Threaded Python, Mindblowing Python GIL, and Changes to the GIL in Python 3.

Interested in documentation? Wesleay J. Chun is giving a talk on writing books using Python and Open Source Software. This will likely talk about Sphinx. Take some time to watch Brandon Rhodes talk about Sphinx at PyAtl.

Interested in PyPy? Maciej Fijalkowski is giving a talk on the speed of PyPy. Take some time to watch the PyPy status talk from PyCon 2009.

Don't go to PyCon unprepared!

Today I'm releasing Python Miro Community. This site is a Miro Community focused on Python. It brings together videos from Python conferences, local user groups, screencasts, and tutorials.

I'm working on it in my spare time because:

1. I think it's really important to get this video out to a larger audience, and
2. it's really important to make it easier for users and developers to find video they're looking for.

This site helps on both fronts. The first in that it collects video into one place without re-hosting it. The second in that I'm curating the site and through better descriptions and tags, the video becomes more findable.

It's not finished--it's an ongoing project that I'll continue to work on. My ultimate goal is to connect with Python video producers like Carl Karsten (whose work is phenomenal), conference A/V people, local user group A/V people, and all those people out there making screencasts, tutorials and project status videos to make sure Python Miro Community stays relevant and continues to helps creators and consumers.

It's free. I'm doing this in my spare time, Participatory Culture Foundation (the non-profit behind Miro) is providing the server and resources to host the site, and the video on the site is available for free on the Internet.

Spend some time today to take a look at the site, browse the PyCon 2009 and DjangoCon 2009 videos, spend some time honing your Python skills with either the Python basics or Python advanced tracks, follow along with the ChiPy or PyAtl local user groups, and see what's out there.

Love it? Hate it? Let me know in the comments.

Thank you to Carl Karsten and Steve Holden for their help pulling this site together!

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• we released a 3.0 rc1 and it's looking really good
• we're planning to do an rc2, get wider testing, and possibly do a release next week

Miro Community 1.0 status (roadmap)

• we're working on 1.0 now--probably a 4-6 week dev cycle

Paul:

• fixed a couple of bugs with comments
• fixed some other bugs with RSS feeds
• fixed the disk space problem on Monday
• working on moving thumbnails to S3

Janet:

• we did the Miro 3.0 rc1 release on thursday
• did regression testing on Windows
• blogged release on Miro Testing site and sent an email to the mailing list
• we've had around 100 downloads of rc1
• we're ready for blogging it on the main blog
• excited about 3.0--things are really coming together

Will:

• busy week
• did bugzilla housekeeping
• wants to upgrade bugzilla to the latest version
• did some basic Miro extensions work

Old wiki page about extensions: https://develop.participatoryculture.org/trac/democracy/wiki/extensionsystem. There is also an old (obsolete) section in the journey about extensions: https://develop.participatoryculture.org/trac/democracy/wiki/thejourney.

Luc:

• fixed some minor issues in master
• working on fixing the downloader daemon shutdown slowness
• +1 on doing an rc2
• thinking about playback-during-download for a future release
• wants to get unit tests working on OSX

Ben:

• checked in some more changes into master that should go out with 3.0 and suggests we do another RC.
• still working on vlc-related fixes

bugzilla

• 17 bugs/feature-requests created
• 2 bugs marked DUPLICATE
• 10 bugs marked FIXED
• 1 bugs marked INVALID
• 1 bugs marked INCOMPLETE

Today I read You can't crowdsource software. The title sums up what it's about.

I've had this experience with Miro. We occassionally get patches from non-PCF people but most of the work is done by PCF developers. We've spent a lot of time and effort over the last few years on getting more code contributors and reducing the barriers to entry. We haven't had much success.

However, there's a lot of other "stuff" that goes into developing an application and the article only focuses on code. Some of this "stuff" can be successfully crowdsourced without a lot of effort. For example, Miro crowdsources all of our strings translation work through Launchpad.

I work on another project called PyBlosxom. We have a core group of developers (right now this is me) who do the bulk of the core code work. I do some plugin work, but the bulk of the plugin work is done by users of PyBlosxom many of whom have never touched the core code. For PyBlosxom, plugin development is crowdsourced.

The article suggests that it's a waste of time to help bring new contributors come up to speed and contribute because they often don't contribute much. That conclusion really concerns me. How can we get more people helping out if we're not working on getting people to help out?

Jono Bacon wrote an article titled Project Awesome Opportunity which talks about a few projects that are reducing the barriers to contributing and making it a lot easier. It's very Launchpad-centric, though.

OpenHatch is a startup working on building the next generation of contributors and connecting contributors to projects that need help. They're wrestling with how to effectively fix these problems, but without tying the fix to a project development silo (e.g. Launchpad, GitHub, ...). I think that's really important.

I think systems like these will reduce the effort in getting contributors and make it easier to crowdsource code contribution.

And if you, dear reader, are looking for a project to help out on that's written in Python and need someone to mentor you, let me know.

February 5th, 2010: I should clarify I think the article is fine. I don't think the conclusion that code contribution doesn't crowdsource well is poorly formed or anything like that. Just that the implications suck.

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• we're really close to a release candidate now--just squaring away some issues that have popped up and letting the code bake

Miro Community 1.0 status (roadmap)

• we're working on 1.0 now--probably a 4-6 week dev cycle

Ben

• Fixed bugs.
• Feeling great about 3.0.
• Has a few more things to do, but is pretty much set for 3.0 things.

Luc

• Fixed bugs for 3.0.
• Worked on testing. Started seeing memory leak issues.
• We can release even with the Perian issue as long as we mention the issue in the release notes.

Janet

• Going through testing and bugs and keeping up with changes.
• We're really close to release-candidate worthy.
• Worked on performance testing and testing on OSX--lots of performance fixes in 3.0.

Will

• Fixed bugs.

Paul

• Worked on Miro Community post 0.9 issues.
• Now working on 1.0. Looking at a 4-6 week time frame.

bugzilla

• 33 bugs/feature-requests created
• 3 bugs marked DUPLICATE
• 23 bugs marked FIXED

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• went through P1s one by one to figure out where we were with them all
• need help testing
• shooting for a release candidate as soon as we can

Miro Community 1.0 status (roadmap)

• Miro Community 0.9 was released!
• working on 1.0 now

Paul

• rolled out Miro Community 0.9 (w00t!)
• 308 Miro Communities out there
• working on 1.0 now

Janet

• split time between testing Miro Community and Miro
• working on Miro regression testing
• continued building regression tests in Eggplant

Luc

• got his Internet connection back (w00t!)
• updated overlay pallette in OSX code to display subtitle items all the time
• worked on slow first-playback issue on OSX
• reimplemented MultilineTextEntry for OSX widgets
• worked on fixing up Edit Item dialog
• tracked down Perian developers and asked about their release timeframe for 1.2.1

Ben

• worked on a ton of Miro 3.0 bugs
• working on VLC playback issues; testing out vlc bindings

Will

• reworked GStreamer playback video renderer
• did a huge pylint pass

bugzilla

• 24 bugs/feature-requests created
• 5 bugs marked WORKSFORME
• 1 bugs marked INVALID
• 2 bugs marked DUPLICATE
• 3 bugs marked WONTFIX
• 19 bugs marked FIXED
• 3 bugs marked INCOMPLETE

Spent a while figuring out how to get Miro to handle media keys in Gnome. My current understanding (and this could be entirely wrong) is that as of 2.18, Gnome handles the multimedia keys. In order for your application to respond to multimedia keys, you have to connect to the signal through dbus.

My biggest problem is that my web searching revealed a lot of bugs, but no documentation. I did finally find Handling multimedia keys in GNOME 2.18 and then worked out the rest. I still have no clue where to find the documentation for it.

Here's what I got working:

import logging
import dbus

from miro import app

class MediaKeyHandler(object):
    def __init__(self):
        self.bus = dbus.Bus(dbus.Bus.TYPE_SESSION)
        self.bus_object = self.bus.get_object(
            'org.gnome.SettingsDaemon', '/org/gnome/SettingsDaemon/MediaKeys')

        self.bus_object.GrabMediaPlayerKeys(
            "Miro", 0, dbus_interface='org.gnome.SettingsDaemon.MediaKeys')

        self.bus_object.connect_to_signal(
            'MediaPlayerKeyPressed', self.handle_mediakey)

    def handle_mediakey(self, *mmkeys):
        for key in mmkeys:
            if key == "Play":
                app.widgetapp.on_play_clicked()
            elif key == "Stop":
                app.widgetapp.on_stop_clicked()
            elif key == "Next":
                app.widgetapp.on_forward_clicked()
            elif key == "Previous":
                app.widgetapp.on_previous_clicked()

def get_media_key_handler():
    try:
        return MediaKeyHandler()
    except dbus.DBusException:
        logging.exception("cannot load MediaKeyHandler")

If you see problems with this, let me know so I can ammend the code.

I keep seeing people say things like, "I'm not a programmer, so I can't help."

I think this is a common misconception about Free Software. Free Software empowers you. Let me say that again...

Free Software EMPOWERS You.

Miro is a Free Software project and like all Free Software projects, there are a variety of ways that you can be involved. By being involved you are taking the responsibility to help solve your own problems.

You can test nightly builds and release candidates.

You can submit bugs and help us triage and fix them.

You can send in patches. Patches can be for code, documentation, packaging, ...

You can package Miro for other distributions.

You can translate strings.

You can tell your friends and family about Miro and help them get setup. You can blog about Miro. You can dent about Miro.

You can adopt a line of code. This helps fund ongoing development. If we had more funds, we could have more paid developers.

Miro is built and maintained by all of us working together contributing our time and resources. There are features to be implemented, bugs to be squashed, systems and software to integrate with, standards to develop--the future is great with possibilities. There's a lot of stuff that can be done and you can help the Miro community do it.

On the dev conference call today we talked about how many things have been fixed, changed, implemented, et al in the Miro 2.6 development cycle. We decided this isn't a .1 improvement--it should get it's own major version number.

As such, we're changing the version number for the next version of Miro from 2.6 to 3.0.

The effects of this are pretty small--it's just a name change. However, our Bugzilla Roadmap urls are specific to a version.

Instead of using:

http://bugzilla.pculture.org/roadmap.cgi?product=Miro&target=2.6

Use this:

http://bugzilla.pculture.org/roadmap.cgi?product=Miro&target=3.0

minutes

Miro 3.0 status (roadmap) (was Miro 2.6)

• went through the last P1 bugs one by one
• need more outside testing
• shooting for a release candidate next week
• renaming to Miro 3.0

Miro Community 0.9 status (roadmap)

• 0.9 will get released monday (new themes, new awesome, ...)
• almost there.... doing bug fixes now

Janet

• spent time regression testing on Windows and OSX
• worked on subtitle support tests
• worked on eggplant tests
• planning to work on Miro Community 0.9 testing for the rest of the week

Ben

• worked on getting external subtitle files working with vlc
• working on other vlc quirkiness
• worked on some other stuff

Will

• synced translations, finished up dependency upgrades on Windows, fixed gst_extractor, fixed moviedata_util, fixed a bunch of little bugs, added tests, peer reviewed code, updated copyright dates, upgraded to libtorrent 0.14.8, did some bug triage, and implemented most of the item edit dialog.
• has a week or two of work left on Miro 3.0

Paul

• worked on the last feature bits for 0.9
• working on bug fixes now--almost done

bugzilla

• 26 bugs/feature-requests created
• 21 bugs marked FIXED
• 5 bugs marked WORKSFORME
• 3 bugs marked INVALID

minutes

Miro 2.6 status (roadmap)

• Waiting on Perian fix.
• Getting close to feature freeze.

Miro Community 0.9 status (roadmap)

• Developing is coming along very nicely.

Janet

• Worked on regression testing, found some issues which were fixed.
• Working on building automated tests with Eggplant.

Luc

• Worked on issues for 2.6.
• Followed Ben's footsteps. Fixed mediatype checking working, sidebar update indicators, and some other things.
• Worked on sidebar scrollbar issues.
• Working on connecting subtitle files with items.
• Most recent bugs are taking a lot longer.

Will

• Had a crummy week.
• Fixed some issues, but didn't get much of what he wanted done.

Ben

• Implemented media type checking.
• Animated the update indicator in the sidebar.
• Fixed the Windows shutdown crash bug.
• Totally awesome performance fixes.
• Fixed a bunch of other issues.

Paul

• Implemented editor comments.
• Worked on flat pages.
• Worked on Miro Community 0.9 stuff--it's coming along nicely.

bugzilla

• 26 bugs/feature-requests created
• 11 bugs marked FIXED
• 1 bugs marked WORKSFORME
• 1 bugs marked INVALID

minutes

Miro 2.6 status (roadmap)

• Ben landed a ton of awesome performance fixes.
• Will worked on fixing unit tests and getting unit tests to pass on Windows.
• Development is progressing nicely.

Miro Community 0.9 status (roadmap)

• Paul is working diligently on it.

Janet

• worked on tests Miro Community
• worked on tests for getmiro.com
• started working with Eggplant to writing automation tests for Miro but ran into a problem with text recognition
• went through the regression tests with Miro and only found a few issues

Will

• working on the Windows build box and trying to figure out why it hangs at night like a naughty naughty machine
• spent serious quality time with unit tests; more to do, though

Luc

• working on small irritating bugs that are hard to reproduce and some of them seem to work fine (i.e. no bug)
• working on support for connecting subtitle files to videos
• talked with Perian folks and they fixed the bug Luc submitted; we're waiting on the next version of Perian

Paul

• was on vacation most of last week
• working on Miro Community 0.9 things

bugzilla

• 11 bugs/feature-requests created
• 2 bugs marked WORKSFORME
• 2 bugs marked INVALID
• 2 bugs marked DUPLICATE
• 4 bugs marked FIXED
• 2 bugs marked INCOMPLETE

This was a pretty big year for the Miro project and the first year for the Miro Community project. In Miro-land, we pushed out Miro 2.0 which was a complete re-write of the user interface. Then we pushed out Miro 2.5 which was a rewrite of the storage/database layer. We also switched from svn to git. That's three really big changes for a single project in one year.

Miro 2.5 was a messy release and we've made a bunch of changes so we don't have to go through that again. We've been spending time on the unit test, QA automation, and code quality for Miro 2.6. We've changed the release process so that it buffers more time to catch issues. We're doing more peer review of complex code changes. The switch to git will help since branching and merging are much easier and less error-prone.

Bugzilla stats:

Overall statistics
------------------
                                  2007  2008  2009
Opened reports at end of year:     453   705  1102
Opened:                           4052  1625  1593
Closed:                           4368  2032  1654
Users created:                     644  1083   771
Comments created:                13564  7529  8329

"Opened reports at end of year" is the total number of opened bugs at the end of that year. So at the end of 2007, we had 453 open bugs. At the end of 2008, we had 705 open bugs, ...

I wasn't sure whether to include 2007 or not since half way through that year we switched from Trac to Bugzilla. No one needed to create an account in Trac, so user numbers should be lower. Also, we were getting a lot of Trac spam, so comment, opened and closed numbers were much higher.

Bugs closed by activity:
------------------------
             2007  2008  2009
fixed         736   932   969
invalid       170   133    85
wontfix        35   142    71
duplicate     139   313   190
worksforme    169   344   151
incomplete      0    57    84

I thought this was an interesting data set.

The INCOMPLETE status was added mid-2008. We use this for whenever we ask a user for some information that we need to work on a bug and the user never gets back to us. It's better than marking it as INVALID or WORKSFORME since it's easier to find this set of bugs that were pushed to the side because need more information.

We're fixing on average 3 bugs a day--that's pretty impressive.

Top 10 bug reporters:
--------------------
   444 - Janet (PCF)
   183 - Anne Jonas (PCF)
    71 - Will Kahn-Greene (PCF)
    71 - Dean Jansen (PCF)
    42 - Nicholas Reville (PCF)
    39 - sg
    37 - Keith Lard
    28 - Uwe Hermann
    28 - Ben Dean-Kawamura (PCF)
    22 - Pan  ~ dietmar

Out of 1593 bugs, PCF employees reported 839--that's just over half. Of the non-PCF people in this list, Uwe is the Debian packager for Miro and Pan is an OpenSUSE packager for Miro. sg and Keith Lard both run OSX.

Top 10 bug closers:
------------------
   421 - Janet (PCF)
   369 - Paul Swartz (PCF)
   353 - Will Kahn-Greene (PCF)
   195 - Ben Dean-Kawamura (PCF)
   114 - Luc Heinrich (PCF)
    26 - Christopher Webber (PCF)
    21 - Dean Jansen (PCF)
    20 - sg
    19 - Anne Jonas (PCF)
    14 - Nicholas Reville (PCF)

Top 10 bug commenters:
---------------------
  2050 - Janet (PCF)
  1757 - Will Kahn-Greene (PCF)
   823 - Paul Swartz (PCF)
   533 - Ben Dean-Kawamura (PCF)
   354 - Anne Jonas (PCF)
   254 - Nicholas Reville (PCF)
   234 - Dean Jansen (PCF)
   187 - Luc Heinrich (PCF)
    98 - sg
    88 - Uwe Hermann 

Git stats

Moving along, I can now get stats out of our git repository. git ftw!

In 2009, we did 11 releases (22 releases if you include release candidates) of which 2 were MASSIVE code overhaul releases. Miro 2.0 involved a re-write of the user interface using native widgets which resulted us in dropping 4,000 files from the codebase (a large portion of that was probably locale-related). Miro 2.5 involved a re-write of the database layer. We had a lot of bug fix releases to stabilize things after these two big releases.

Between Miro 1.0 and 1.1: 1606 files changed, 127775 insertions(+), 14605 deletions(-)

Between Miro 1.1 and 1.2: 2318 files changed, 233370 insertions(+), 185511 deletions(-)

Between Miro v1.2 and v2.0: 4715 files changed, 271506 insertions(+), 560366 deletions(-)

Between Miro v2.0 and v2.5: 662 files changed, 169258 insertions(+), 175292 deletions(-)

Half of the 2.0 work and all of the 2.5 work was done in 2009. 2.0 was clearly a monumental release like no other release we've ever done.

In 2009, we did 1,382 commits. For comparison, we did 2,049 commits in 2008. The bulk of the work for Miro 2.0 was done at the end of 2008--I think that accounts for the large discrepancy here.

Contributor stats

I don't have stats for testing contributions or translation contributions so I can't speak to those. I can only speak to patches and bug triage contributions.

In 2009, we had 19 contributed fixes/features. PCF employees are doing the bulk of the work. This is still an area we could use help with.

In 2009, we've done a lot to lower the barriers to entry and make this easier: improved code quality, wrote documentation, improved build documentation, improved build scripts, added unit tests, ... In 2010, we're continuing this work.

Summary

Despite the Miro 2.5 release which was pretty rocky, I think we had a really good year and got a lot accomplished. I'm looking forward to Miro 2.6 (or whatever the next release gets called).

I'd love to see more contributions from other people. If you have some free time or some passion and want to help out, let me know. If you don't have free time, but have some spare change floating around, please donate--this helps PCF pay for employees to work on Miro.

minutes

Miro 2.6 status (roadmap)

• it's coming along

Miro Community 0.9 status (roadmap)

• it's coming along

Paul

• working towards the 0.9 Miro Community release
• tweaking the Windows installer and trying out another installer partner

Luc

• fixing browser-related issues
• working on more Miro 2.6 bugs

Will

• updated the binary kits to libtorrent 0.14.7
• spent time looking at sphinx-gsoc2009 to see if it was usable for a Miro User Manual--it's not

Janet

• working on Miro Community testing
• started to do performance comparisons between Miro 2.5.4 and what's in master after Ben's and Will's performace fixes
• got a license for Eggplant for Miro interface testing

Ben

• worked on performance work that makes things a lot faster for certain operations
• has one additional thing to check in performance wise

bugzilla

• 4 bugs/feature-requests created
• 3 bugs marked DUPLICATE
• 7 bugs marked FIXED

notes

We're working on Miro 2.6 targeted bugs. If there are issues that should be targeted for 2.6, let us know. If there's anything you can help with either by adding information or contributing patches to any of the bugs targeted for Miro 2.6, please do!

minutes

2.6 status (roadmap)

• talked about release planning
• subtitle support almost done
• we want to continue working on performance issues

Janet

• acquiring eggplant for testing
• regression testing on miro master
• tested miro community 0.8.5

Luc

• working on 2.6 bugs

Will

• worked on and submitted the PSF grant
• worked on 2.6 bugs
• doing a pylint pass on the codebase and working on code quality issues
• almost done the subtitle menu changes for linux and windows

Ben

• working on performance issues that happen when doing things with multiple items
• other 2.6 work

Paul

• released miro community 0.8.5 on friday afternoon (miro community 0.8.5 release announcement)
• working on miro community 0.9 (roadmap) with better theme support and other things

bugzilla

• 9 bugs/feature-requests created
• 3 bugs marked DUPLICATE
• 12 bugs marked FIXED
• 1 bugs marked WORKSFORME
• 1 bugs marked INVALID
• 2 bugs marked INCOMPLETE

notes

We're working on Miro 2.6 targeted bugs. If there are issues that should be targeted for 2.6, let us know. If there's anything you can help with either by adding information or contributing patches to any of the bugs targeted for Miro 2.6, please do!

We've been working on subtitle support for Miro in the subtitle branch. Yesterday, Ben merged the changes into the master branch. As of this morning, nightly builds have subtitle support. Yay!

There are still a few things to implement and the code hasn't had much of a chance to settle. Also, there are still some things I think should get refactored and it's likely we'll be tweaking the interface going forward as we use it more.

Still, it's good to have landed the bulk of this feature. It's probably not wildly useful yet, but it gives us some ground work towards building better subtitle distribution/creation infrastructure going forward.

minutes

2.6 status (roadmap)

• subtitle work is almost done
• lots of bugs to work on, but some might have been fixed in 2.5.4--Janet is going to retest
• lots of little bugs to work on left--we could use the help if anyone is interested in contributing!

Paul

• Worked on Miro Community 0.8.5. It's pretty close to done--there are two outstanding bugs.
• Hoping to push out Miro Community 0.8.5 out in the next few days. Lots of bug fixes, cool new administration stuff.
• After that, there are a few big bugs for 0.9 to work on.

Janet

• Worked on getting 2.5.4 out. Looks like it's been a good release with few complaints.
• Working on figuring out the shutdown crash for Miro on Windows. This has been difficult and very trial-and-error.
• Worked on Miro Community testing.

Ben

• Worked with Janet on that shutdown crash.

Luc

• Worked on Miro 2.6 issues from bugzilla. Just kind of going through and cherry-picking easy issues and nasty issues.

Will

• Pushed out 2.5.4.
• Worked on menu refactoring.
• Worked on subtitles stuff.

bugzilla

• 10 bugs/feature-requests created
• 3 bugs marked WONTFIX
• 3 bugs marked FIXED
• 1 bugs marked INVALID

minutes

2.5.4 status (roadmap)

• Will fixed an additional bug on Monday that Janet tested and it looks fine.
• Will is going to build builds today. Then we'll test them and probably do a release Thursday morning and update the appcast file on Friday.

2.6 status (roadmap)

• subtitle work is almost done
• menus need to be refactored to finish up subtitle work
• lots of little bugs to work on left--we could use the help if anyone is interested in contributing!

Paul

• spent the week working on bugs in Miro Community
• started working on custom templates allowing admins to change the way their site works
• ten or so bugs left on the 0.9 roadmap to do
• going to triage the bugs in order to push out a 0.9 sooner

Janet

• working on finding an automated ui tester
• worked on Miro Community testing, too

Will

• did a bunch of fixes
• getting ready to push out a 2.5.4
• plans to work on refactoring the menus next

Ben

• implemented subtitle support on linux
• worked on osx bug fixes
• started looking into VLC freeze issues

bugzilla

• 7 bugs/feature-requests created
• 2 bugs marked DUPLICATE
• 6 bugs marked FIXED
• 1 bugs marked WORKSFORME
• 2 bugs marked INVALID

notes

I wasn't on last week's devcall. Thus, no notes.

I've been talking about removing the xine renderer for 6 months now. I don't do this lightly--generally we want to add features, not remove them. However, we're a _really_ small team of developers working on Miro and one of the things I'm focusing on for the Miro 2.6 development cycle is to reduce and simplify wherever we can so that we can focus on the work ahead of us. Also, the gstreamer folks are doing a fantastic job and that project is really coming along. I feel very confident that switching to gstreamer is a good move.

Today is the day I did the deed. As of c1c6f33, the gtk-x11 platform of Miro no longer uses the xine renderer. This checkin removes all the xine code from the codebase.

A while back, I threw together a VLC renderer that mostly works. Other renderers can be built in the same way--the infrastructure is there for anyone to create new renderers and ship them as separate packages.

Even though this is a good move, I do realize it leaves some people out in the cold. If you are interested in championing the xine renderer and starting a project to build and maintain it, let me know and I'll do what I can to help out.

We've been working on reducing the complexity of the code for Miro 2.6. We've done this in a few different ways and I want to summarize them here.

moved binary kit stuff to separate repositories

This dropped the size of the git repository for miro a lot. Cloning the repository is much faster now. Plus it's easier to build Miro on Windows and OSX from the source tarball.

moving libtorrent out of portable

On Linux, this allows us to rely upon Linux distributions to have packages for libtorrent (the Rasterbar version) and the Python bindings. We don't need to compile libtorrent as part of the Miro build process anymore. That dropped the build time like a rock, reduced the tarball size, and removed a bunch of issues from configuring and compiling Miro on Linux.

removing sorts.pyx and fasttypes.pyx

Removing these allowed us to remove the build dependency on Boost. That removes a bunch of assy code we had in the setup.py file. This also reduced the time it takes to build Miro on Linux.

adjustments to setup.py to be more whiny when things are missing

I added some code to the gtk-x11 setup.py to make it clearer when it's missing build dependencies. I then tested this on Kubuntu Karmic, Fedora 12, and OpenSUSE 11.2. Miro will still try to run if it's missing things--I'll look into this soon.

updated gtkx11 build docs

I went through and updated the build recipes in the gtk-x11 build docs page. I updated the recipes for Ubuntu Karmic, added recipes for Fedora 12 and OpenSUSE 11.2 (though it won't work because I couldn't find a libtorrent rasterbar package), and removed a bunch of old recipes that would never work. I'm planning to do Gentoo and some other distributions next.

I updated the build and runtime requirements lists, too.

removing xine

This hasn't been done yet, but it'll happen soon. This will remove some build requirements and it'll make our lives easier since we'll only have to support one renderer on Linux. Supporting two takes a time and effort and we're only doing a so-so job of it. Better to cut xine loose and focus on gstreamer. I'm sorry that this will affect some people. I'm hoping to rework the code so that additional renderers can be released as separate packages like I did with frontends.

conclusion

We're focusing on reducing the complexity of the codebase and build requirements to make it easier for new people to pick it up, build and contribute. If there's anything else we can do on this front--or better if there's anything YOU can help us do--let us know.

minutes

2.5.4 status

• Ben made some fixes for 12301, those will get merged in.
• Need to sync translations
• A new set of branch builds today and a release at the end of this week or early next week

subtitle support status

• Luc has it implemented for OSX. Still need implementations for Linux and Windows.
• Will's working on the Windows implementation.
• Ben's going to look into moving the menu/submenu code to portable.
• Either Ben or Will will work on the Linux implementation when their plates clear.

Ben:

• spent a while working on bug 12301. bunch of fixes that'll go into 2.5.4.
• researched "pumping up the volume"; looks possible so he's going to implement it.

Luc:

• frustrating week working on gstreamer subtitles support
• had problems getting his test files to play correctly with Miro on Ubuntu Karmic
• wants to hand off gstreamer subtitle support to someone else
• worked on scrollbar problem with osx

Janet:

• tested 2.5.4, tested 12301 fixes, and did a bunch of Miro Community testing

Paul:

• worked on bugs for Miro Community 0.9

Will:

• will merge in ben's 12301 work, sync translations, and make a set of 2.5 branch builds
• will work on subtitle support for windows
• will work on subtitle support for linux

bugzilla

• 9 bugs/feature-requests created
• 3 bugs marked WORKSFORME
• 1 bugs marked INVALID
• 2 bugs marked DUPLICATE
• 1 bugs marked WONTFIX
• 1 bugs marked FIXED

notes

Several people said they read the reports weekly and find them very useful, so I'll continue writing them.

One person mentioned how there's no public information about Miro development. That's not correct. Here's a list of urls of public information:

• Bugzilla timeline http://bugzilla.pculture.org/roadmap.cgi
• Bugzilla roadmap http://bugzilla.pculture.org/timeline.cgi
• Git repository web frontend http://git.participatoryculture.org/miro
• Release notes for releases https://develop.participatoryculture.org/trac/democracy/wiki/ReleaseNotes
• We have #miro and #miro-hackers on freenode.net for IRC.
• Develop mailing list http://participatoryculture.org/mailman/listinfo/develop
• Planet Miro http://planet.getmiro.com/
• Miro blog http://www.getmiro.com/blog/
• Identi.ca group http://identi.ca/group/miro

We switched the miro repository url from https://git.participatoryculture.org/miro/ to http://git.participatoryculture.org/miro/. If you were using https, then you should switch the origin url in the .git/config file. It's unlikely that's the case, though, since it's been broken for over a month now.

A little over a week ago, I started Gnome Miro Community. I'm a Miro developer and we use a ton of Gnome stuff in the application. The site will index Gnome related videos from around the Internet. I hope it'll aid Gnome development.

I started a few categories: gnome-shell, gstreamer, and GUADEC 2009. I'll be adding to these going forward.

One of the big things that I did was to bulk load the GUADEC 2009 videos into Gnome MC. I built an RSS feed, populated it with descriptions of the talks from the Gran Canaria Desktop Summit wiki pages, and pulled it all into Gnome MC. Today I pulled down the videos and generated thumbnails for everything and pushed that up, too. Took about 5 hours in total, but the data is much more useful now.

Gnome MC will do searches every night for new material out there. I'll keep tabs on this queue. If you know of videos that haven't been added either let me know or submit them through the site.

I'm really excited about this site and I'll do my best to keep it going and make it as useful as possible. I hope it helps to make Gnome as awesome as it can be!

I finished the work to remove the binary kit data from the miro repository today. Removing the binary kit data from the repository changed all the shas. To alleviate the problems this causes, I did the following:

1. Ran a git filter-branch --commit-filter that added a line to the end of every commit message stating what the original commit sha was. The shas are referenced in Bugzilla, so this maintains the papertrail.
2. Moved the "old git repository" to miro.old. If you're building Miro versions prior to Miro 2.6, it'll probably be easier to do that in the old git repository because the binary kit material is there.
3. Binary kit materials were moved to separate repositories.

The end result of this is that we went from 900mb for the repository and a full checkout to about 136mb. Clones are faster, it uses less space on disk, and you're not saddled with a bunch of binary date you probably aren't going to use. It's also much easier on the build boxes which are old and don't have a lot of disk space kicking around.

If you have any questions, comments, or problems, let me know.

minutes

2.5.4 status

• Work is going well. There's a new bug that we should look into. But we've done RC builds and we're sending notes to users who are having problems with 12101 in hopes they'll test.
• If things go well, we'll probably do a release in a week.

Luc

• Did most of the implementation for subtitle support in VLC with Miro on Windows. Doesn't have a Windows build environment, so he's passing this off to Ben or Will to finish up on Windows.
• Hoping to have the repository changes done asap.

Will

• Keeping tabs on 2.5.4 rc1 testing progress.
• Helped prisioner on IRC get Miro building on Windows with mingw32. Keeping tabs on that progress with the hope that we can switch from building with Visual Studio 2003 to mingw32.
• Planning to do the big repository filtering today.
• Planning to take on the subtitles in VLC on Windows work for Luc

Ben

• Did a bunch of 2.5.4 work.
• Finished the fasttypes removal work.
• Got some more data on 12301. Going to look into it to see if there's anything we can divulge from it.

Janet

• 2.5.4 rc1 looks good except for bug 12426.
• Continued working on building the test infrastructure for Miro Community. Has two volunteers helping with building test cases.

Paul

• Working on Miro Community features: html editing for comments, fixing the submit a video flow, added an RSS feed for categories, ...
• Back to working on Miro Community bugs.

Nick

• Morgan is going to work on another theme for Miro Community.
• Working on making Miro Community easier to modify.

bugzilla

• 11 bugs/feature-requests created
• 1 bugs marked DUPLICATE
• 7 bugs marked FIXED

notes

Are these reports useful to anyone? No one has commented, no one has mentioned them on IRC or email, ... If they're not useful and no one is reading them, then I should be spending my time elsewhere.

About a week ago, Joe contributed a patch to disable the screensaver on KDE when Miro is playing fullscreen. I don't run any systems with KDE on them. I'd love to get some help testing this patch so that we can include it in the next release of Miro.

The bug for this work is http://bugzilla.pculture.org/show_bug.cgi?id=3067. The patch is at http://bugzilla.pculture.org/attachment.cgi?id=1980.

Let me know whether this patch works or doesn't work for you either in the comments of this blog entry or in the comments of the bug.

minutes

Paul:

• Is sick.
• Bug fixes and small features for Miro Community.
• We have a lot of sites and things seem pretty stable.
• Working on Miro Community 0.9 now. 0.9 isn't very feature-full, but it improves on things for style, look and feel, and such.

Luc:

• Worked a couple of days on subtitle support for Miro on Windows using VLC. Building a test application in C. Once he's got that working, he'll transcribe it to Python and ctypes.
• Switched gears to help Will to fix libtorrent build problems with the new binary kit system. Bumped into problems getting it to compile on OSX 10.4 (expletive expletive expletive). Worked around it.

Will:

• Continued working on libtorrent and binary kit changes.
• Wants to do a 2.5.4 that includes vlc 1.0.3, libtorrent/unicode fixes on Windows, and database fixes from Ben.

Ben:

• Fixed database problems with duplicate ids.
• Spent time removing sorts.pyx and filetypes.pyx from the codebase. This reduces complexity of the build.
• Wants to push out a 2.5.4 with database fixes he's done recently.
• Wants to finish the fasttypes removal work on OSX.
• Talked about the sniffer code.

Janet:

• Tested changes in Miro and Miro Community.
• Working on making it easier to assign tasks to volunteers and get more volunteers involved in the process without losing track of them.
• Wrote up a wiki page for subtitle implementation work and testing. This will become the specification of what we're implementing now that we're mostly done research. https://develop.participatoryculture.org/trac/democracy/wiki/SubtitleImplementationDetails
• Is having her wisdom teeth taken out next week.

bugzilla

• 19 bugs/feature-requests created
• 1 bugs marked DUPLICATE
• 7 bugs marked FIXED
• 1 bugs marked WONTFIX
• 2 bugs marked INVALID

Miro uses libtorrent-rasterbar for bittorrent downloading. We had a copy of the libtorrent source code in the portable section of our repository. Miro would compile libtorrent as a Python extension along with all the other stuff to build Miro binaries. Not any more.

Luc is almost done carrying my changes over to OSX 10.4, but as of today, libtorrent-rasterbar is no longer in the portable section of our repository.

What does this mean?

For Windows, a clean build on our Windows build box went from taking enough time for me to make dinner, eat dinner, and then completely forget what I was working on (26 minutes) to 4 minutes. In my Windows XP vm, a clean build went from 8 minutes to 1 minute. Plus I fixed the unicode problems Miro had with Windows and libtorrent and updated Miro to use libtorrent 0.14.6 on Windows.

For OSX, a clean build on my mac mini running OSX 10.5.8 went from 17 minutes to 1 minute. Plus I updated Miro to use libtorrent 0.14.6 on OSX, too.

For gtk-x11, libtorrent is now a required system package. Miro will no longer compile its own libtorrent if you don't already have it installed. I'm pretty sure that most modern versions of the major Linux distributions have packages for libtorrent-rasterbar and the Python bindings.

We have a couple of other changes that affect the project structure almost done. I'll blog about them as they finish landing.

11/4/2009 - This is completed now. Many thanks to Luc who sorted out the issues I was running into with compiling libtorrent on OSX 10.4 with Boost 1.35.0.

minutes

Paul:

• Worked on Miro Community stuff over the week.
• Talked about infrastructure for the MC services.

Janet:

• 2.5.3 looks like a pretty good release.
• Tested Will's torrent-related fixes--looks good.
• Testing Luc's subtitle work. Found some bugs with the subtitle code and older versions of OSX. Otherwise, it's looking good so far.
• Talked a bit about Miro Community testing. We have a few volunteers helping, but there's still work to do.

Luc:

• Worked on subtitle stuff. Happy to see people are starting to test subtitle-enabled builds.
• Worked out some bugs so it now works on 10.4, 10.5, and 10.6.
• Working on getting subtitles working on Miro on Windows with VLC.
• This is coming along nicely and we decided it should land in Miro 2.6 so we're going to move the work to the master branch.

Will:

• Reworked Miro on Windows to use a packaged binary kit.
• Switched Miro on Windows to use a pre-built libtorrent from the binary kit.
• Planning to do the same for Miro on OSX.
• Pushed out a set of Karmic packages for 2.5.3, but they aren't well tested.

Ben:

• Did some bug-fixing.

bugzilla

• 23 bugs/feature-requests created
• 12 bugs marked WORKSFORME
• 1 bugs marked INVALID
• 2 bugs marked DUPLICATE
• 3 bugs marked WONTFIX
• 3 bugs marked FIXED
• 25 bugs marked INCOMPLETE

I just pushed out packages for Karmic for Miro 2.5.3. Until Karmic is out, consider these packages beta quality. If you use these packages and run into problems, let us know as soon as you can.

Ubuntu installation instructions

minutes

Nick and Luc weren't on the call. Janet and Will had colds. Ben's side of the call had some weird 15 second delay. That made it a dicey call that we ended on IRC.

Minutes for this morning's call:

Paul:

• Working on Miro Community finishing up version 0.8.

Ben:

• Worked on a lot of bugs, especially 12101. Checked in a few fixes into master which look pretty good, but need testing.
• Worked on a bunch of other bugs.
• Worked on 12229 to allow for distribution of RSS and content on a DVD.

Will:

• Worked on extracting binary kit stuff from the repository.
• Planning to work on Karmic packages for 2.5.3.

Janet:

• Sick.
• Hoping to get to testing the changes Ben made for 12101.
• Spent some time testing Miro Community and is getting geared up to start testing Luc's subtitle code.

bugzilla

• 14 bugs created
• 2 bugs marked FIXED
• 1 bug marked DUPLICATE
• 1 bug marked INVALID

The Miro 2.5 series has been a total pain in the ass--I'm not going to lie. Not only has it infuriated a number of users, but it's been like a Sysaphusian struggle for the team.

Right now there are 3 developers (Ben, Luc and myself) and 1 QA person (Janet) that work on Miro fulltime. Then we have a large community of testers, translators, and a handful of people who send in patches to fix the problems that irk them most. Even with this large community, the majority of the development, testing and support is done by 4 people.

In the last three months, Janet's house was hit by lightning frying a bunch of her testing machines; I bought a house and moved (along with the build boxes); Ben went on vacation for a month; Luc bought an apartment, moved, and then had his Internet connection totally hosed for a month; I had unforeseen medical problems (that I don't really want to talk about), that resulted in me being offline for the last two weeks; and our ssl certificates expired.

This week is the first time since the beginning of August when we've had all 4 of us working.

We've been trying so hard to get a much-needed 2.5.3 release out. It has a slew of fixes that should alleviate an array of problems that users have been experiencing. We're finally on the verge of the release. I hope it'll happen today or tomorrow.

I really appreciate the patience many of you have had with us as we scrambled to do the impossible over the last couple of months. I really wish it could have happened differently, but it's as if the forces of nature were completely against us.

Though 2.5.3 should fix a variety of issues, we're working on re-architecting some portions of Miro that aren't working well with the database changes we made in Miro 2.5. On top of that, we're working on subtitle support, extensions, and continuing to make Miro a better experience for a larger group of people. Some/most/all of this will show up in Miro 2.6 and 2.7, hopefully in the next few months.

note

I wasn't on the call for 10/7/2009, so I don't have notes for that day.

minutes

Will:

• Planning to push 2.5.3 out.
• Planning to keep working on extracting binary kit stuff.
• Then get miro working on Karmic Koala.
• Then moving libtorrent out of portable.
• Will be in Providence, RI from October 23rd through 26th.

Luc:

• Continuing work on subtitle work.
• Perian doesn't support subtitles in subfolders. Luc is looking into fixing Perian and then sending a patch upstream.
• Luc is going to start looking into VLC support next.

Ben:

• Planning to work on 12101. One of the theories is that when torrents are downloading, Miro is doing a lot of disk thrashing.
• Remove torrent metadata from the updates.
• Tweak status so that we only persist to disk every now and then.
• Plans to work on bug 12229.
• It's difficult to figure out how many people are affected by 12101.

Paul:

• Working on Miro Community 0.8 release. It's coming along nicely.

Janet:

• Tested Miro Community and Miro 2.5 branch builds.
• Working on testing plans for Miro Community post 0.8 release.

2.5.3 status:

• Talked about 12277 and 12276 and where we're going with that plan.
• Hopefully we'll get it out today or tomorrow.

bugzilla

• 8 bugs created
• 1 bug marked DUPLICATE
• 4 bugs marked FIXED
• 2 bugs marked WORKSFORME
• 1 bug marked WONTFIX

minutes

Minutes for this morning's call:

Janet:

• Has gone through all of the tests on Windows XP for 2.5.3 rc1.
• Working on testing Miro on OSX.
• 2.5.3 rc1 is looking good so far.

Luc:

• Worked on 12212 and should have it fixed tomorrow.
• Worked on subtitle ui--it's coming along nicely.
• It's hard to determine which subtitle thing is which language which makes it hard to allow users to choose a default subtitle language.
• Worked on external .srt subtitle handling.
• Perian doesn't support external .srt for movie containers it doesn't open by itself (mp4, quicktime, ogg, ...). Luc's running into problems with that and is trying to talk to the Perian developers.
• VLC handles everything created so far just fine. Luc's tossing around ditching Quicktime/Perian for VLC. (ed note: I think I summarized that right--but I could be completely mistaken about what Luc is tossing around.)
• Will continue doing subtitle work in a subtitle branch that'll eventually get pushed to g.p.o.

Ben:

• Hopped on the call to say hi.

Will:

• Worked on 2.5.3 bugs, put out a rc1 release.
• Working on redoing release process, scripts and infrastructure to make releases easier and cleaner with git.

Paul:

• Working on Miro Community--almost done with version 1.0.
• Working on unit tests.

kickstarter

We achieved the $1000 goal in large part to a couple of key donations. Thank you!

bugzilla

• 21 bugs created
• 7 bugs marked FIXED
• 1 bug marked DUPLICATE
• 8 bugs marked INCOMPLETE
• 2 bugs marked INVALID
• 1 bug marked WONTFIX

minutes

Minutes for this morning's call:

Luc:

• Working on fixing problems with 10.6 build environment and getting Miro working on 10.6.
• Working on subtitles. (Please help us fund this!)
• Having issues with .srt files rendering with Perian and 10.6.
• Snow Leopard support is targeted for 2.5.3.
• Talked about subtitle implementation specifics.

Will:

• Working on trying to get 2.5.3 out.
• Working on 12101.

Janet:

• Testing fixes targeted for 2.5.3.
• Working on Miro Community testing. Planning testing and manual testing.
• Suggested we build a pre-rollout/pre-demo checkoff list for testing.

Paul:

• Worked on Miro Community and it's almost at the 1.0 point.
• Miro Community still needs polish, documentation, testing plans...
• Two sites are live now.
• There are a bunch of sites on deck.

kickstarter

Subtitles project on kickstarter has 24 backers for $494. We're hoping it clears $1000 by the end of the month--8 days to go.

bugzilla

• 19 bugs created
• 4 bugs marked FIXED
• 3 bugs marked DUPLICATE
• 1 bug marked WONTFIX
• 2 bugs marked WORKSFORME

summary

Every Wednesday morning we have a conference call that we call the "dev call". This has been happening for years. Mostly we use it as a place to schedule upcoming development, talk with each other about problems we're working on, and come up to speed on where we're all at.

I occasionally take minutes when someone isn't on the dev call. I'm experimenting with posting the minutes on this blog for the next month. If it turns out to be useful, I'll keep doing it. Otherwise I'll stop.

minutes

Minutes for this morning's call:

Luc:

• working on getting Miro working with Snow Leopard.
• cleaning up the sandbox code.
• it'll make things much easier when we drop support for 10.4--but that's far in the future still. (15% of OSX users are using 10.4 according to Miro Guide stats.)
• then we talked about the costs of supporting 10.4 users.

Will:

• worked on Miro 2.5.3 and 2.6 all week.
• talked about bug status for 12028, 12150, 12166, 12101, and 12108.
• talked about how we're building libtorrent and how we should bump it to the binary kit which will definitely alleviate some issues and possibly alleviate others because we're not really building it "right" in the first place.
• made changes to Planet Miro and took over curating.

Janet:

• got her machine back which was fried by lightning in August.
• working through reworking her test environments.
• testing the Miro 2.5 nightly that Will built.

Paul:

• working on Miro Community.
• almost done with merging "users" and "authors". should get resolved in the near future.
• continuing to implement styling stuff from Morgan.

kickstarter

Subtitles project on kickstarter has 12 backers for $191. We're hoping it clears $1000 by the end of the month.

bugzilla

Rough Bugzilla stats:

• 16 bugs created
• 8 bugs marked FIXED
• 4 bugs marked as DUPLICATE

I appointed myself Planet Miro curator this morning. I also made some changes:

• added new related links
• added an about page
• added Uwe Hermann's Miro tagged feed
• added Open Video Alliance feed

Going forward, I'll blog about Planet updates.

Who else should be on Planet Miro? We're interested in getting content and updates from anyone who contributes to Miro, Miro Guide, Miro Community, Open Video, or any of the other endeavors that we're working on.

If there are blogs or people you know of whose work should be synidcated on Planet Miro, email me to let me know.

As of September 11th, there are only 10 people in the world who are interested in subtitle support in Miro enough to contribute to it. Is that right? Were we completely mistaken in thinking that users want subtitle support?

If subtitle support in Miro is important to you, take the time to contribute now. If you live in the United States, donations/contributions are tax-deductible because PCF is a 501c3 non-profit company.

Also, help us get the word out. Write about it on your blog, dent it, digg it, reddit it, ... Help us make it happen. Help us help you.

How do you contribute to Miro development?

Do you test nightly builds and release candidates?

Do you submit bugs and help us fix them?

Do you send in patches?

Do you package Miro for other distributions?

Do you translate strings?

Do you tell your friends and family about Miro and help them set it up? Do you blog about Miro?

Did you adopt a line of code?

Miro is built and maintained by all of us working together contributing our time and resources. There are features to be implemented, bugs to be squashed, systems and software to integrate with, standards to develop--the future is great with possibilities.

We at PCF are testing out feature-focused support to help pay our operating costs. We're going to pick a feature every release and turn it into a project on Kickstarter. If the feature that we picked is important to you, then pledge and help PCF help you. These aren't little features--they're big projects that implement functionality that's often requested.

For the next next release, we're working on subtitles. If subtitle support is important to you, then check out the project page and pledge your support. Help PCF continue its work on Miro. Help me and the other PCF developers help you.

Things have been slow for the last week and will probably remain slow for the next week, too, mostly due to real life sorts of things among the various developers. We took advantage of this slow period (it doesn't happen often) to switch Miro development from svn to git. This is something we've wanted to do for a while and should make the development process we have a lot easier to deal with.

To summarize, things are slow right now, but they'll definitely pick up again in September.

I finished up the work for converting our svn repository to git and pushed the whole thing to the server. You can follow along at https://git.participatoryculture.org/miro/.

I'll be spending the next week or so updating code, infrastructure, and documentation to reflect the change.

We're switching the Miro repository from svn to git. This frees us up considerably and will make development life a lot easier for us. We chose git over other dvcs systems because most of us were already using git-svn to access svn and we're already using git for Miro Guide, Miro Community, Miro Fullscreen and other projects.

For the last week or so, I've been converting the Miro svn repository to git. It's taken a long time because I ran into several complications:

1. I've been moving from an apartment to a house which sucked up a few days.
2. We treated tags in svn like branches: we'd tag a release, then make some adjustments "in the tag". Tags in git are immutable which is a good thing--they should be immutable. I've spent a bunch of time figuring out how to convert our svn tags into git tags and tweak the history accordingly. It takes around 20 minutes to fix each instance of the problem and there were a lot of instances of it--one for each release, release candidate, beta, .... Many many thanks to James Vega for helping me out on this.
3. I'm running out of disk space on my laptop. I've had to do some archiving to free up space and that's taken a while.

Hopefully, I'll be done in the next day or so. Once I finish, I'll push the new git repository to a public space, have the other devs run through it for issues, post a message about it on the develop mailing list and then I'll start work on changing build scripts and other things like that to use the git repository rather than the svn one.

One thing that's happened as a result of this work is that I've really come to appreciate git internals and how it's all structured. I have no idea how Bazaar and Mercurial structure things, but git's pretty neat.

Update 8/17/2009: My math was way off. I've got another 50 tags to go at 20 minutes per tag that's at least another couple of days.

The folks at FLOSS Manuals put together a Theora Cookbook. It's a great book that covers Theora and publishing video on the Internet.

It's definitely worth reading/skimming if you're interested in Open Video, Theora, and the impending future of video on the Internet.

We released Miro 2.5 a couple of weeks ago and it was a messy release which resulted in a Miro 2.5.1 a day or two later and a Miro 2.5.2 a few days after that. It sucked. I wish it had been better.

Before a release has happened, a messy release looks like any other release: development has wound down, lots of bugs have been fixed, a bunch of new features have been implemented, testing is going well, people who have looked at the nightlies and release candidates like the new features and haven't encountered any issues, ... Then we decide to pull the trigger and push it out.

It's only when a release is out that the messy release rears its ugly head and the obviousness of its messiness is revealed. Usually this is made abundantly clear by abusive emails from people who encounter problems with the release, become frustrated, and express themselves with abusive vitriol aimed at me and all the other people who worked hard on the release.

It's at this point, I bite the bullet, prepare for the world of pain I'm about to get involved in, and try to reach out to as many people as I can, gather information to identify the issues so that we can fix them, and provide support to people who are encountering problems to enable them to get through them.

So what the hell happened with Miro 2.5?

Miro 2.5 started out with a big flaw: there was no upgrade dialog showing when Miro was transforming the database from the old style to the new style. If you have a small database like mine (8 mb), you'd never notice. People who had huge databases would launch Miro 2.5 for the first time and ... seemingly nothing would happen for minutes. The person would assume Miro isn't starting, would kill the process, and then try again. At this point, Miro would see a wedged database and wouldn't start. We think there were on the order of 30,000 downloads at this point and we had maybe 50 people who had problems.

We recognized the problem and we kicked into emergency mode. Janet and I worked the GetSatisfaction forums, blog, and identi.ca. Ben poured over the incoming data, made a few fixes and put in a progress dialog. We pushed out Miro 2.5.1. Janet and I went through and talked to each user who had problems to help them unwedge their database and get back to a working Miro.

A day or two later, we found another couple of problems. I made some fixes and pushed out Miro 2.5.2. Then I wrote a script people could run to re-download data that was lost. Dataloss totally sucks. We did everything we could to help alleviate the problem after we found out it was there.

There are still a bunch of people for whom Miro doesn't work. I'm talking with a few of them. Others have given up. It's always been the case that there are people for whom Miro doesn't work and we do what we can to figure out the causes.

And that's where we are now.

Going forward, we're going to figure out how to better test Miro release candidates. We thought that 600 people would have fleshed out most of the issues, but it seems that there are classes of people whose usage patterns aren't reflected in our testers and testing. If you can help us with testing, we'd love to have you. You will have a direct impact in making Miro better.

Going forward, I'm going to work on making it easier for Miro to help people identify problems and let us know. I'd also love to get some help fixing Miro so that it doesn't lose data when things go wrong. Code contributions would help a ton here.

Going forward, I'm going to ask for help more often. There are only 4 PCF developers and we're spread very thin between Miro, Miro Guide, Miro Community, and the other things we're working on. We need your help. This isn't a new situation. What is new is that I'm going to do a better job making it explicit what I need help with right now.

I love working on Miro. I love what Miro is doing for people and for communities. I love our mission. I need your help to help me help you. Miro is your project as much as it is mine.

I hope the initiatives we're working on will eliminate messy releases in the future.

The Miro 2.5 release had a couple of issues that affected users with large databases. We've been working on those issues and helping those people out for the last couple of days. This work culminated in a Miro 2.5.1 release.

Because I was working out issues with Miro 2.5 release and helping users work through issues (more on that in a future blog post), I haven't worked on the Ubuntu packaging yet. My current plan is to wait until Sunday (tomorrow) and do packages for Miro 2.5.1 skipping 2.5.

I apologize for not getting packages out sooner, but I:

1. was busy fixing Miro 2.5 issues and helping users
2. thought it'd be better to hold off until the Miro 2.5 issues were worked out
3. discovered World of Warcraft

If for some reason I can't/don't push out packages on Sunday, I promise I will do them as soon as I can. I use Ubuntu, too, so this affects me as well as all of you.

If for some reason this isn't satisfactory and you want/need it sooner than I can provide, I encourage you to build your own Miro from source. There are instructions here.

We released Miro 2.5 today. It's a great release and a big step for Miro. My favorite features are:

• audio playback that doesn't suck
• handling for torrents that have folders and multiple files in them
• video/audio tabs instead of new/single
• totally redone database layer

The last feature is a big deal--we rewrote the entire storage layer for Miro to do it. Miro went from a pickled Python object database to a relational database. With the new database system, you can do things like this:

willg@mercury:~/.miro$ sqlite3 sqlitedb
SQLite version 3.6.10
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select count(*) from feed;
23
sqlite> select origUrl from feed;
dtv:manualFeed
dtv:singleFeed
dtv:search
dtv:searchDownloads
dtv:directoryfeed
http://www.fileden.com/files/2008/5/14/1911312/timostrailers.rss
http://feeds.feedburner.com/Gitcasts
http://www.youtube.com/rss/user/googletechtalks/videos.rss
http://feeds.feedburner.com/Screencastersheathenxorg
http://www.whitehouse.gov/rss/speeches.xml
http://www.hd-trailers.net/blog/feed/
http://pycon.blip.tv/rss
http://feeds.feedburner.com/CSS-Tricks-Screencasts
http://www.g4tv.com/xplay/podcasts/6/XPlay_Daily_Video_Podcast.xml
http://feeds.theonion.com/OnionNewsNetwork
http://www.npr.org/rss/podcast.php?id=35
http://feeds2.feedburner.com/YourWorldIn5-itunes
http://g4tv.com/cinematech/podcasts/8/G4_TV_Cinematech_Video_Podcast.xml
https://fedorahosted.org/releases/f/e/fedoratv/fedora-tv.xml
http://openmeetings.org/archives/ovc2009-sessions-mirofeed.rss
http://ubuntudevelopers.blip.tv/rss
http://makezine.com/blog/archive/make_podcast/index.xml
http://www.podshow.com/feeds/gbtv.xml
sqlite>

This is the first big step in making Miro more hackable and more accessible to projects like Coherence, Elisa, and others. It'll also make it a lot easier to debug database problems in the future.

Note: After you've upgraded to Miro 2.5, Miro will upgrade your database to the new structure on the first startup. This takes a long time depending on how big your database is. Just let Miro hang out and do its thing. The epic fail here is that there's no ui indication that Miro has started and is upgrading the database. I'm hoping we'll fix that soon.

I hope you're happy with the improvements in Miro 2.5. We're not resting there--work has already begun on Miro 2.6.

When you Adopt-a-Line at the Miro Adoption Center, you're contributing to the continued development and maintenance of Miro and the MiroGuide in addition to helping us work on our mission to ensure that video is healthy and accessible to everyone and that Open Video flourishes. This is something that's really important to me and I can't thank people enough for their contributions that enable me to do the work that I'm doing.

We're getting really close to a Miro 2.5 release. If you adopt a line before Monday, July 20th, then we'll make sure your name shows up in the "About Miro" credits for Miro 2.5. If you adopt after that, we'll make sure your name shows up in the next version, but that'll be a few months down the road.

If contributing is as important to you as it is to me, take the time now to adopt! It only took me a few minutes, and I've got a cute baby Zowwee Kahn-Greene!

I threw together a VLC renderer for Miro on gtk-x11 based on the VLC renderer code we use for Miro on Windows. It took an hour or so to get it working.

I'd love to toss it in into Miro, but it's got one major problem and one minor one.

The major problem is that VLC handles mouse events rather than letting them bubble up to Miro. When you double-click on the a video, VLC handles the double-click and switches the video to fullscreen (or out of fullscreen). It'd be better if Miro handled this--then it could show the media item details bar. Also, VLC handles mouse movement. Miro needs to handle this, too, so then it can show the item details bar.

The minor problem is that VLC doesn't have libvlc_video_track_count in versions prior to 1.0. I'm not sure how else to figure out if a media file has video tracks in it. Because of this, the sniffer code is pretty ham-fisted if you have earlier versions of VLC.

The code is at http://bluesock.org/~willg/download/vlcrenderer.py if you're interested in fiddling with it. There's documentation at the top of the file that walks through installing and using it.

I'd love to get some help fixing it. Adding support for VLC and dropping support for xine on gtk-x11 would make things a lot easier for us Miro devs.

Ben checked in a fix for database problems that occur when a user's disk is full. This fix required the addition of 4 new strings. I really apologize for making strings changes this late in the development cycle, but we decided the fix was really important and that outweighed the imperatives of the strings freeze.

We're on the brink of releasing Miro 2.5. It's something we're hoping to do early next week--possibly Monday or Tuesday pending how Ben's changes bake out.

Because of this, we really need help with translations. If you're a translator, have done Miro translation work before, and/or know someone who has, now's the time to spend some time with translations to ensure that they're rock-solid for a Miro 2.5 release.

For the last month, I've been going through the house-buying process. Today we found out we were approved for a mortgage and so now we're all set.

Thus, it's official: PCF-Boston will be moving and will become PCF-Chelmsford.

I plan to continue co-working, but I'll be doing it in the Chelmsford/Lowell area. ^[1]

There are a few ramifications. The first is that it'll be harder to take me out for a cup of coffee if you're in the Boston area. The second is that I probably won't be going into the FSF offices to help with mailings anymore. The third is that there will likely be a period of a few days in the middle of August when the build boxes will be down and there won't be any nightlies.

One of the big boons is that my office will double in space which should make it easier to get more things done since I'll have room for additional equipment, monitors, and such. And I'll have more space to produce podcasts and screencasts and such.

As a sidenote, the house-buying process is fricking insane. And not in a good way. Thank goodness for gscan2pdf, Gimp, Thunderbird, Postfix, Debian, Ubuntu, and the dozen smaller bits that made my side of the paper-pushing much much easier.

[1] Where "continue" is defined as "start coworking again which I haven't done in a long time because I just haven't had time to organize things".

During the Miro 2.5 development cycle, I've been working on getting better developer documentation cobbled together. It's a huge task that'll take us a while to do.

The initial focus of this developer documentation is two-fold:

1. provide web-based documentation for architecture, modules, classes, methods, functions, ...
2. codify project standard practices

This is important because it makes development easier for core developers, but it's even more important because it'll make it easier for casual contributors to figure out where everything is and how it works.

This is in addition to the documentation found at the Miro Development Center (aka our Trac wiki). Some content will move from the Miro Development Center to the developer docs, but we'll have both for a long time to come.

The first pass for developer documentation for Miro 2.5 is at http://pculture.org/wguaraldi/miro/2.5/developer/. It answers such questions as:

• how do I add support for a new search engine? (see here)
• how do I help translate Miro? (see here)
• where's all the database code? (see here)

There's a lot more to do, but it'll get better over time if people spend time on it.

For those interested, I'm making heavy use of Sphinx. You can see the source from the developer documentation by clicking on the "Show source" link on the left hand side. The source for the documentation is in our svn tree at https://develop.participatoryculture.org/trac/democracy/browser/trunk/docs/developer.

Miro is nearing a 2.5 release candidate. There are only a couple of things we're waiting on now like a VLC 1.0 release. I'm hoping for a release candidate as late as next week and a final a week or two after that depending on how well the release candidate works for people.

If you're a Miro translator, the strings are frozen and we sure could use your help getting up-to-date accurate translations for Miro 2.5. If you know someone who's done Miro translations in the past, let them know that we're rapidly approaching the 2.5 release.

As a reminder, Miro 2.5 is the "trunk series" on Launchpad. Don't translate the Miro 2.0 series--changes there won't be carried over to trunk unless you do it yourself. The Miro trunk series translations page is here.

Now for the gripe. In the last week, Launchpad did an update which changes the translations pages and they no longer tell you the last updated date for individual translations. That's a real drag. I used that field to figure out whether or not to export translations from Launchpad and import them into Miro and to watch translation activity. Grumble grumble grumble.

I'm subscribed to all downstream Miro bugs in the Fedora bug-tracker. I'm also subscribed to all downstream Miro bugs in the Debian bug tracking system. It helps a lot to triangulate issues with external component versions and the myriad of other problems that come with developing an application that runs on Linux distributions.

Today, Rudd-O, who I've never met, ranted on the state of the Miro codebase in bug 494505 in the Fedora bug-tracker. I responded with this https://bugzilla.redhat.com/show_bug.cgi?id=494505#c13.

I thought I should blog about that since I really don't blog enough about the whos and the whys and the hows of Miro development.

After Miro 1.2, we decided to embark on some serious rewrites to fix big problems with the way Miro was structured. Thus each major version since Miro 1.2 has involved signficant overhaul.

Miro 2.0 saw a re-write of the ui. In doing so, we rewrote the Windows platform code which used to be a XULRunner application but is now a Python application using GTK. The ui rewrite fixed a lot of internal codebase problems, but the primary use case was to fix performance problems when displaying feeds with lots of items in them. Display isn't perfect, but it scales a lot better now. As a side note, it's not that we didn't like XULRunner, it's that we wanted to merge the windows and gtk-x11 platforms to make it easier to develop going forward.

Miro 2.5 (not quite out yet, but hopefully soon!) involved a re-write of the data storage code. It is a good thing to do in general, but the primary use case here was to fix performance problems with startup. No longer does Miro need to load the whole database to load the ui; now it can do it in parts. This speeds up Miro startup for a lot of people especially those with large databases. As an added bonus, the database is a regular relational database which other programs can access to see Miro managed media and metadata.

We don't have plans for the next version yet, but there's still a lot of stuff to re-write and make better. The downloading code needs refactoring. The feedparsing code needs good regression tests and once we have good regression tests, it should get refactored. There's a lot of code that needs to be documented and cleaned up. We need to add support for new standards and specifications. We need to add support for really important features like subtitles. We want to build a plugin framework allowing people to extend Miro in their own ways to meet their needs.

That's what we're working on, but there's no way we can do it all at once. We could use your help. If you can't contribute code, contribute funding for someone else to dedicate the time to work on code.

We are all Miro users. We are all Miro evangelists. We are all Miro testers. We are all Miro developers. Miro was made by you and me for you and me. Long live Free Software and Open Video!

I adopted a line of Miro code today. Her name is Zowwee Kahn-Greene. She's pretty cute. :)

If you want to adopt-a-line, you can do so at the Miro Adoption Center.

I just got back from the Open Video conference and it was really inpsiring and really awesome. From when I arrived in NYC late Thursday night to when I left this morning, the time flew by. I met a variety of people who have a stake in the Open Video game: producers, directors, creators, distributors, publishers, companies, representatives, individuals, codec hackers, renderer hackers, player hackers, site builders, community builders, independent journalists, movers, shakers, ...

I met a co-worker I've worked closely with for some months, but never met (and didn't realize who he was until after he was introduced). 7 out of 10 (or so) PCF staff were all there--the largest number of PCF staff in one place I've been a part of. Ben, Paul and I were able to do some Miro work and talk about issues we're having pushing 2.5 out the door. I met with Jean-Baptiste from VideoLAN (they make VLC) and talked about their impending 1.0 release (I scored a pre-release tarball and already started working on upgrading Miro on Windows to use VLC 1.0). I talked about metadata with a few people and I talked about problems with torrents in RSS enclosures with Kevin and Nathan (I'm pretty sure that's his name) Michael from LimeWire on things they're working on that have a lot of synergy with things we're working on. I talked with Joe Born from Neuros Technology about work I did in March on the Neuros Link and how we should go forward working out issues that Miro has when running on the Link (it runs well, but could use some ui tlc). Seeing what people are thinking about and doing with HTML 5 video tag was great.

It was a really productive conference for me. It's really clear what role Miro plays in the future of Open Video on the web. It'll be exciting to be a part of the future unfolding.

6/23/2009: I met Michael from LimeWire--not Nathan.

My jury duty trial finished up yesterday freeing me up for going to the Open Video Conference. The conference schedule looks pretty interesting. I'll try to hit development related things as much as possible.

Sunday is going to be a hackfest day--looking forward to seeing other Miro devs and devs from related projects and working on the future of Open Video.

If you're at the conference, say hi!

Participatory Culture Foundation is the non-profit organization I work for working to build a distribution system for video and audio on the Internet that has no bottlenecks, no filter points, uses open standards, and Free Software.

Most of the software that we write is written in Python. Miro, an Internet video player, is written in Python and runs on a variety of platforms. Miro Guide and Miro LocalTV are both systems that are written in Python using Django. Miro Fullscreen is written in Python using Clutter.

Python has made it possible for a very very small group of us to tackle such a large project with very limited resources.

Earlier this week, we launched our Adopt a Line of Code, a fundraising campaign to help us fund the work we're doing. No one has ever done a fundraising campaign like this before. We think it could be a good model for other Open Source and Free Software projects to raise funds.

Take a moment to check out the Adoption Center and adopt your very own line of code! Support us in our work to make video open for everyone.

I spent the greater part of today adding remote control support to the Miro Fullscreen project. I thought I'd do a write up on it because there are a lot of pieces involved and it took me ages to figure it out and I'm paranoid I'll forget.

Quick caveats:

• I'm doing this on Ubuntu Intrepid (8.10). If you want to translate this to your favorite distribution, feel free to add any notes in the comments.
• If you're using OSX or Windows and want to know how to get things working there, I have no idea how to do it and that's not going to be covered here.
• I used a StreamZap remote and didn't try it with other remotes.
• This is a set of notes; it's not a good essay and I'm definitely not an expert.

Requirements

I installed three packages: lirc, python-pylirc, and gnome-lirc-properties.

sudo apt-get install lirc python-pylirc gnome-lirc-properties

LIRC

lirc has a web-site at http://lirc.org/. I had no idea what I was looking at while wandering aimlessly through that site. I think the important pages are these:

• http://www.lirc.org/html/configure.html - covers the .lircrc file format
• http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap - covers the codes for the StreamZap; there are other code pages at http://lirc.sourceforge.net/remotes/

python-pylirc

The only useful site I could find for this project was at http://pylirc.mccabe.nu/. It says that Paul Hummer took over the project and moved it to http://pylirc.ironlionsoftware.com/, but that's a dead link. I found Paul's blog at http://theironlion.net/blog/. He uses tagging on his blog, but there's only one article tagged as pylirc2 at http://theironlion.net/tag/pylirc2/. I couldn't find anything useful about pylirc, the project, its status, or what's going on. Paul suggests he was going to add LIRC support to Entertainer, but it doesn't look like he ever did that.

Anyhow, so I ended up going with the documentation on http://pylirc.mccabe.nu/ and that seemed to work out ok.

gnome-lirc-properties

I don't know if I really needed gnome-lirc-properties.

The .lircrc file

So you install the three (or two--depending on whether gnome-lirc-properties is really needed) packages and you create a .lircrc file like this:

begin
    prog   = mirofullscreen
    button = MUTE 
    config = n
end
begin
    prog   = mirofullscreen
    button = VOL_UP
    config = Up 
end
begin
    prog   = mirofullscreen
    button = VOL_DOWN
    config = Down 
end
begin
    prog   = mirofullscreen
    button = UP 
    config = Up 
end
...

where prog is the string you pass to pylirc.init, button comes from the remote control lirc file and config is the string you add handling for in your application.

the Python code

The sample code at http://pylirc.mccabe.nu/?/article/articleview/Documentation/1426&themex=public gave me enough of an idea on how it worked to implement the code in Miro Fullscreen.

In closing

Hope that's useful to someone at some point.

I'm heading to Portland, OR for OSCON 2008 to help man the Mozilla booth at the Expo. I registered as an Expo attendee, but I'll be there (or near there) from the 19th through the 26th.

My primary purpose there is as a representative for Miro and talking to people about it. However, I'm also interested in meeting up with people working on:

• PyBlosxom things
• Miro and video podcasting things
• Python 2.6/3.0 testing, documentation, bug-fixing, ... things

If you're interested, too, ping me. I'm hanging out on the #oscon channel on irc.freenode.net and you can always get me by email or comments below.

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

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.

The company I work for is looking to hire a few able Python developers. Instructions and details about the job are on the PCF jobs page.

This is the best job I've ever had. I get to telecommute which really works for me. My co-workers are all able fantastic people. The mission is really important and affects everyone. The work that we're doing is FOSS and we're working with and contributing to other FOSS projects. I've covered the board in terms of projects from bug fixing, to adding enhancements, to debugging upstream components, to Ubuntu packaging (which I need some more practice with), to test systems, to Firefox 3 patches, to Firefox plugins, ... I've also had my hands in Bugzilla adjustments, infrastructure, build systems, ... It's been challenging and interesting ever since day 1.

I've also been meeting a lot of people I otherwise wouldn't have met: Chris Blizzard and John Ressig at Mozilla, SJ at OLPC, Holmes Wilson at Downhill Battle, Asheesh at Creative Commons, and others. It's exciting.

That's my experience at PCF in the last 6 months. If you're looking for a telecommuting Python development job, think about applying.

I put out Gutsy, Feisty and Dapper builds for i386 for Miro 1.1.1 on Tuesday when we did the Miro 1.1.1 release. But... I'm using new scripts and I goofed up the miro-data package. I didn't have time to figure out the problem, so I attempted to back out the Gutsy amd64 packages and in the process screwed up something else.

I thought I had it all working by Tuesday night, but there were a couple of users that were still experiencing "size mismatch" errors on the miro-data package. So I took some time today to figure out how to deal with the miro-data package I was building, roll up a set of Miro 1.1.1-3 packages for Gutsy i386 and amd64 and push everything out.

Theoretically there should be good Gutsy i386 and amd64 packages for Miro 1.1.1 in addition to the Feisty and Dapper i386 packages I rolled out Tuesday.

Sorry for the delays. I think things are straightened out now. If you're still having problems feel free to leave a comment below and/or find me on IRC or by email.

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.

It was a pretty wild year for me. I had a massive health crisis at the beginning of the year, wrote an almost-working compiler for a functional language using SML targetting SPIM, finished up grad school, got married, landed a job at Participatory Culture Foundation, made a lot of new friends, mentored a GSoC project, helped out with GHOP, started the big push for PyBlosxom 2.0, released a new version of Bee Careful, Marvin under a CC BY-NC-SA 3.0 license and submitted my first patch for Firefox 3.0.

I started the Nomadic Telecommuting Herd which has regular meetings, but hasn't extended beyond Chris and I, yet. I'll push this more at some point in the spring when it's more fun to go outside.

I also joined a few projects that I haven't been able to get to yet like the Python docs project and Geyser. I'm interested in helping out both of them, but haven't found the time yet.

This year I want to tame the firehose, get some good work done, participate more in other projects, possibly learn C++ and reach out to other people in the area (Somerville, MA, USA) to get together and hack more. I'd also like to get a new laptop, but the longer I wait, the better the possibilities become.

I work for Participatory Culture Foundation as a developer on the Miro internet video player.

Today we released Miro 1.0. For most of the projects I've worked on, the 1.0 mark is exciting to reach, but also somewhat of a downer because it really requires you to hone the list of all possible things you could do down to a small finite list. Inevitably, there are things people will want to do that 1.0 doesn't do. Still, it's a huge milestone for the project. We're already working on post-1.0 development and making changes to decisions that didn't turn out as well as we had hoped.

A good portion of the work we do is in Python with lots of interaction between Python and libraries written in C and C++. For example, we use a lot of Pyrex to speed up critical sections.

Miro is a great product to continue to push open standards for video distribution and consumption on the Internet. I regularly watch GoogleEDU videos through Miro and I'm hoping other Python-related channels will be available as well. At some point, I'd like to create my own Python-videos channel and aggregate good Python-related video content. There's a lot of screencasts and tutorials out there....

It's been a crazy few months... I worked like crazy the last two weeks of grad school, got my Masters, got married, went on a honey moon (or toffee moon depending on where you live), pushed out a new version of PyBlosxom, and ... got a job! I'll be a developer on the Democracy Player (soon to be Miro) at Participatory Culture.

I'm really psyched about this. Hopefully it nicely weds my Open Source/Free Software development hobbies with employment. Hopefully it nicely weds the way I like doing software development with the way I have to do it for work. Regardless, it's nice to be working in one major language (Python) rather than two (Java and Python). Also, there's a lot of really neat technology that PCF is using that I haven't worked with before--so it'll definitely be a growing experience.

I start next Monday (July 16th). Because I'll be doing Python development for employment, it'll be a lot easier to focus on Python-oriented things and blog more about Python the language, tools, methodologies and all that, too.

Today was my last day at work for the summer at ByAllAccounts. I spent the beginning of the summer doing backend work and then hit a showstopper with the project I was on. Then I spend the second half of the summer working on extending our Custodial Integrator product to work with Advent APX (it already worked with Axys). It was interesting, but I preferred the first project I was working on because I was doing it nuts to bolts: research, project plan, scheduling, work, testing, and quality control.

I told them I'm not going to work during the fall semester. I think with the two classes I'm taking, I won't be able to give BAA enough time to be effective/useful.

I'm currently working for ByAllAccounts and I've been here for 15 months now. It's an amazing company filled with a tight group of amazing people.

Forrester did a report on the wealth aggregation space and ranked us at the top. It's been the cause of much excitement around here. And much deserved.

Link to the report.

Link to my company's website.