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.

The work we were having done to the new house is done, we moved in, and we're settling down now. S wanted a couple of rooms painted, so I and a handful of awesome people did that over the weekend. The living room is set up (we can finally sit on the couches) and I've started bootstrapping the office. That means I can finally get some serious work done.

We're outside of Boston now. If you're in the area and want to hang out, I'm definitely game. I haven't done any research to see what groups are in the area yet, so if you know Linux, Python, Miro, FSF, or other kinds of groups, I'd be interested.

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.

Updates:

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.

I'm moving this week. That's why I haven't been online much or doing any work on Miro, PyBlosxom or other things I usually work on.

It gets better! After I'm done moving, I'm heading up to my parents' place while we have work done on the house. I'll be there for a couple of weeks. I'll have Internet access and will be working, but my cell phone doesn't get reception up there, so I'll be out of touch in a different way.

Assuming all goes well, I'll be back home and everything will be totally groovy in September.

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.

I was reviewing something and learned that Python saves the original sys.stdin, sys.stdout, and sys.stderr as sys.__stdin__, sys.__stdout__, and sys.__stderr__ respectively. That's pretty handy to know. Works in at least Python 2.5 and up--I didn't test earlier versions.

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.