I'm at FUDCON10 right now (Thursday, 6/19/2008). I'm interested in meeting people here and talking about Miro and Fedora TV. If you're here, come find me. I'm currently hanging out in the main FUDCON room in the corner all by myself. ;)

We've had a few people contributing patches for the Miro codebase. I decided it was time to add a review flag like Mozilla has in their Bugzilla instance. This makes it easier for us to keep track of attachments that are waiting on reviews.

As such, I added a "review" flag to our Bugzilla instance for attachments.

I thought I'd talk a little bit about contributing patches.

Guess what? You're a happy Miro user except for one little thing that really annoys you. You head on up to the Miro Bugzilla bug-tracker to see if this is a bug/feature that someone else has reported already. Wow--turns out it has been reported. Not only that, but there's been some analysis done and some speculation as to a good attack vector for fixing the problem.

So you roll up your sleeves, add a comment on the bug stating you're going to work on it, set yourself as "assigned", dust off your favorite editor, skim through the Miro development wiki for the svn repository information and build instructions, and get to work.

A few hours later you've got it working on your machine. You run:

svn diff > bugid.patch

to generate a .patch file containing the changes you've made.

You visit the bug in the Miro Bugzilla bug-tracker, find the bug you were working on, and click on "add attachment". You'll see the following screen:

Deftly, you upload the patch, click on the "patch" checkbox, select "?" from the Review flag dropdown and type in will.guaraldi@pculture.org in the Requestee box.

Then you press the "submit" button!

Will (that's me) gets an email stating that there's an attachment waiting for review. I add it to my queue of things to look into. If it's not something I know anything about, I'll find someone else who can look at it. Then someone will add a comment to the bug reviewing the patch and ... the rest is iterations on that.

If you're interested in helping out, we've been tagging bugs that we think are good for people new to the codebase as "bitesized". You can see a list of them here.

I was the Q&A person for the June 3rd chat yesterday and I thought I'd post some follow-up and answer some of the questions we didn't get to.

Follow-up

First off, I thought the chat went well and it was neat to talk to a bunch of people I'd probably never talked to before. It seems that the predominant theme was "when are features landing?" and "what's coming up?" It's a little hard to answer those questions because I've been pretty focused on the next release that I haven't been involved in planning beyond that.

Now to answer some questions that we didn't have time for.

How long have you worked for PCF? What did you do before Miro?

I've been working at PCF since August 2007. This is in many ways my dream job with my only issue being that I wished I either earned a bit more money or had a lower cost of living. Other than that, I'm doing what I love doing, I get to hang out with some really great people, and the stuff we're working on is really important to me.

I'm going to assume "What did you do before Miro?" means "What did you do before working at PCF?" Prior to PCF, I spent 2 years getting a Masters at Northeastern University CCIS in programming language design/theory and software engineering. Prior to that, I worked in the financial services industry at ByAllAccounts, I worked as a contractor for Tallan at Ingram Micro on their international web-site system, and various other software developer positions before that. I've been programming for probably 20 years now in various forms, but this is my first FOSS job and the first job where I've worked with XULRunner and GNU/Linux-stack components like Gtk+, GStreamer, Xine, Glade, DBus, Glib, GObject, ... It's been great!

shoestring: Video metadata: any plans to see miro actually writing it to the files/being able to edit it?

We've talked about making ui changes to allow for changing "metadata" of content, specifically name, filename, tags, ... It hasn't happened yet, though. I think it's one of many things waiting for the great widget overhaul.

Miro can export feed information to OPML format, but this doesn't include metadata about content. I don't know offhand if there are plans to add that or not. There are plans on building an API to allow programs like MythTV and Elisa and other systems like that access to Miro data. That hasn't happened yet, either. In this case, I think it just needs someone to work on it.

Evan: Is it possible to install miro without bittorrent? I know this question is weird, but in some (many?) companies bittorrent is banned ... yet the company is ok with limited internet video usage.

We don't have builds that don't have bittorrent in them. It would take some work to decouple Miro from libtorrent and/or disable it and then it sounds like we'd have to provide a separate set of libtorrent-less builds. I don't think that's a bad idea, but I don't think it's going to happen without a champion who can do the work.

will: (seed question) What do you do when you're not working on Miro-related things?

A little silly answering my own seed questions, but ... so it goes.

Lately all I've been doing is Miro-related things. We're pushing really hard on the next release. We're really excited about it and we think it's another big milestone in Miro's life.

This year, I'm a backup admin for GSoC for the PSF thought I haven't actually had to do much (yet).

I've been trying to finish up work on version 2.0 of PyBlosxom for the last 6 months but haven't found time and energy to get there. I've been able to make some progress, but it seems to be on a permanent back-seat.

I'd really like to help Mozilla on their embedding efforts. I'd also really like to get more involved in gstreamer, Python 3000 and a bunch of other projects.

Epilogue

I think that's about it. Given that the chat went pretty well all things considered, there will probably be another one in the future and probably more after that.

I live in Somerville, MA, USA and I'd like to organize a Miro hackfest in or near Boston. Possible topics for that hackfest include:

• cleaning up and improving the gtkx11 platform interface, gstreamer/xine use, ...

• working on bitesized bugs and working on unittests

• hacking together an interface for Elisa or MythTV

• testing out the fledgling Mozilla embedded API with the gtkx11 interface

• sorting out packaging issues

• other things?

I was thinking we'd do the hackfest sometime in June. Possibly as part of FUDCon10 or in the vicinity.

If you're interested and/or have ideas, find me on IRC, email me, comment below, or send me telepathic messages of hope.

• (r6949, bug 9908) gstreamer renderer uses gconfvideosink now--much better video output

• (lots of revisions) new user interface

• (lots of revisions) Windows ui looks and acts like Mac OSX ui

• (bunch of revisions) all unit tests pass

Am I missing anything? Let me know in the comments.

Back in December and January, I worked on some patches for Firefox 3 that enhanced the feed preview page. I wrote a post about it back then, but I'm updating that post with recent screenshots and a better description of the work. The previous post was mostly about how great FOSS is.

The patches fell into two big features. First, I added enclosure detection to the FeedProcessor and then modified FeedWriter to show enclosures alongside the entries. This has two huge benefits: it allows you to easily tell if the feed has enclosures and it allows you to see what they are, how big, what type of media, ...

Second, I modified Firefox so that it allows you to associate video podcasts with an application, audio podcasts with another application, and all other kinds of feeds with a third application. The benefit here is that you can send media podcasts to an application that handles that well (cough*Miro*cough) and regular news feeds to a different application that handles that well.

Screenshot of Firefox 2 feed preview page:

Screenshot of Firefox 3 feed preview page:

Of the two features, I hear the most comments about the first one mostly along the lines of, "I'm so glad I don't have to view source to see the enclosures anymore!" The second feature isn't as immediately exciting. The implementation of distinguishing feeds is intentionally simple and there are a lot of corner cases where it doesn't work very well. Also, there aren't many applications that can really take advantage of it. I expect this second feature to flourish as Firefox development continues and video/audio podcasting evolves.

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

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

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

I volunteered at ROFLCon yesterday and today. The whole experience was really surreal but fantastic! I thoroughly enjoyed the sessions I attended while "on duty" and the new friends I made. I also came home with a sticker that says "Bacon is a vegetable". That sums that up.

A couple of days ago, I did a dist-upgrade on my server which runs Debian. I'm not sure what version I had prior to the upgrade, but after the upgrade I'm at 1.6.2. The problem is that the wiki syntax is different, so my wiki data was mildly hosed. I ended up spending 45 minutes to an hour trying to figure out how to migrate the data.

The magic script is /usr/share/python-support/python-moinmoin/MoinMoin/script/moin.py. You need to run it like this:

$ ./moin.py --config-dir=/path/to/wikiconfig.py/dir/ migration data

The other problem I had is that I had no meta file in my data directory and so the moin.py script would die with a stack trace like this:

Traceback (most recent call last):
  File "./moin.py", line 24, in ?
    run()
  File "./moin.py", line 15, in run
    MoinScript().run(showtime=0)
  File "./../../MoinMoin/script/__init__.py", line 138, in run
    self.mainloop()
  File "./../../MoinMoin/script/__init__.py", line 251, in mainloop
    plugin_class(args[2:], self.options).run() # all starts again there
  File "./../../MoinMoin/script/__init__.py", line 138, in run
    self.mainloop()
  File "./../../MoinMoin/script/migration/data.py", line 44, in mainloop
    curr_rev = meta['data_format_revision']
  File "./../../MoinMoin/wikiutil.py", line 472, in __getitem__
    return dict.__getitem__(self, key)
KeyError: 'data_format_revision'

I assumed that I had some version of 1.5 previously and so I created a meta file with this in it:

data_format_revision: 01050800

After doing that, the moin.py script worked nicely and all my wiki data is in the correct syntax now.

Update:

4/26/2008 - Fixed some words to make the meta file creation step clearer.

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

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

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