Will's blog

PyBlosxom uses Sphinx for documentation now. I was having problems with using -- for em-dash and it not showing up like an em-dash in the HTML output.

The docutils FAQ says to use the actual unicode character for emdash. I don't really want to do that because I'm not sure about what happens when the source files are opened up by a non-unicode-friendly text editor.

Turns out that doesn't matter because Sphinx allows -- for en-dash and --- for em-dash. Is this something that should get added to the Sphinx documentation?

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