First Mumble Tracker Squash Meeting

Posted on July 7, 2010 by slicer

Over the past few months, most of the Mumble team has been busy with other projects. This has lead to an unfortunate build-up of unsolved bug and feature requests. This Sunday, we had our first developer meeting to address this.

Every now and then, real life and other projects have to take priority over Mumble development. Since about mid-march, the only requests we’ve really done anything about has been patches. Bug reports and feature requests have been put on the “todo” list, which by now has become pretty long.

In an effort to address this, this Sunday saw our first developer meeting (held using Mumble, of course). This saw quite a few results, which I’ll go through in turn.

First of all, 1.2.3 is now more or less feature komplete. Krejler has a block of OSX interactive overlay code that is missing, and .D0T, pcgod and other contributors are working hard on finishing an initial version of audio recording. The current plan is to get these features in, resolve any bugs that remain and then release 1.2.3. With a bit of luck that will happen inside of a month.

As a consequence of the above, that means the 200 feature requests we currently have unresolved in the tracker will not be addressed for 1.2.3. Once 1.2.3 is out, we’ll start going through the requests and implement things that look fun or make a lot of sense. In the meantime, we’re currently evaluating replacements for the feature request tracker itself. While the tracker works well for bugs, it lacks a few features we’d like to see for feature requests, such as popularity tracking, milestone targets and easy marking of duplicates. SF.net is currently implementing SF.net 2.0 and maybe that will improve things. If not, we’ll probably need an alternative.

Most of the meeting was spent triaging bug reports. All bug reports should now either have been assigned to a developer for fixing, set pending with request for more information, or left open because triaging them takes a lot longer. As it turns out, this triaging is a good thing, as it allows all of us to work independently on fixing specific bugs, which means we should have a fairly bug-free snapshot ready inside of a week.