Category: Community

Please help test our new search server

Paul Taylor and Aurelién Mino have completed the re-write of our search server — please help us test this new code-base. Here is Paul’s write up:

This update rewrites the existing Search Indexer and Searcher with a
pure Java release whilst maintaining full compatibility with the
existing Musicbrainz Server, prototype by luks, completion by ijabz and
murdos. The aims were

1. Better performance

Search performance should be greatly improved for indexing and
especially search.

The intermediate python layer has been removed.
The webserver layer has been removed
When searching have a single Java VM , that can now be properly
configured/optimized
The latest Lucene and Java libraries are used

2. Better Search Results

The following bugs have already been fixed

Perhaps most importantly stop words are no longer and issue so when do a
search for something that exists in the database you should always get a
match, i.e artist:”the the” or track:”is this it?”

example

and range queries work properly

i.e

example

and theres a host of other bugs and enhancements that can now be
resolved quite easily

bug list

3. Maintainability

The code has been simplified, i.e no hand coding of xml or html or
having to deal with escape characters.
Now has a full set of unit tests, can also easily generate metrics such
as code coverage reports.
No dependency on Linux or Python, making it easier for new developers
to contribute, removing the burden from ruaok.

Testing Stage

Please try it out on http://musicbrainz.homeip.net both as a websearch
and as an XML Service to find any omissions in functionality and any
situations where the search results aren’t good as before.

Paul / ijabz

Google donates another $30,000!

Google’s Open Source Office has once again decided to support MusicBrainz with another $30,000 donation! Read about how we use Google’s money on the Google open source office blog:

Last year, Google’s generous donation paid for a much needed server and it allowed us to hire our Google Summer of Code™ student (Oliver Charles) part time after the program wrapped up. The donation also helped pay for mundane things like keeping the lights on, backup disks and paying for insurance. But the most fun part that we spent money on last year was our phenomenal MusicBrainz Summit in London.

Thank you very much to everyone at the Google Open Source Office! MusicBrainz would be moving slower and be much more dull without your support!

Looking for a new maintainer for pymb2 and libdiscid

Matthias Friedrich (yalaforge) finds himself with little spare time on his hands these days and has asked me to find a new maintainer for the Python MusicBrainz library (pymusicbrainz2) and for the C based libdiscid library. While libdiscid doesn’t require immediate work, the pymb2 library needs to have support for Release Groups (from the 2009-05-24 server update) added in.

Matthias suggested that anyone interested in becoming the maintainer should write a patch to add the needed release groups support. I think this is a good idea — anyone interested?

If so, please post a comment!

And thanks for your hard work on these projects Matthias!

UPDATE: Our Help Wanted page has been updated to reflect our current needs.

Wiki Migration

Today’s the day – our wiki is being migrated to MediaWiki.  The old “moin” wiki is now read-only (and will remain so, at least for a few months), and is available on oldwiki.musicbrainz.org.  The new wiki, once all the data has been migrated across, will be at the usual address.

As soon as the migration is complete, I’ll switch wiki.musicbrainz.org over to point to MediaWiki.

Unfortunately it won’t be possible to also migrate the user accounts from moin to mediawiki, so regrettably this means that once mediawiki us up, you’ll have to re-create your accounts.  Sorry about that.

Update: the switch has been made – if you have any questions to ask or problems to report about this, please see the WikiMigration page.  Thanks!

MusicBrainz Flickr machine tags

Sander van Zoest and Dan Brickley have been prodding me to officially post about Flickr Machine tags — using Flickr machine tags you can now tag your photos on Flickr to refer to specific MusicBrainz entities. This is how to create MusicBrainz machine tags on Flickr:

  • musicbrainz:artist=<MBID>
  • musicbrainz:release=<MBID>
  • musicbrainz:track=<MBID>
  • musicbrainz:label=<MBID>

For more details see the official wiki page: FlickrMachineTag

Wanted: Wiki, Documentation, Trac and UserVoice guardians

In working on figuring out how to integrate UserVoice into our workflow its become painfully clear that we need to have some people take “ownership” over a few portions of MusicBrainz. Back in the day when Cristoph König (Don Redman) was our Wiki warden, our wiki was well groomed and worked smoothly. Alas Cristoph has been swallowed whole by a University in Germany and we may never see him again. 🙁

Its time to find volunteers who are interested in taking on personal ownership of these aspects of MusicBrainz. I’m looking for 2-4 volunteers, one for each of the following areas described below. However, please note that these people are not expected to carry out the bulk of the work that needs to be done to get these projects into an improved state. I envision each of these people being motivators and leaders who can focus and encourage the efforts of other volunteers to help them achieve their goals — there is a big difference between a leader and a workhorse.

  1. Wiki: This person should be well versed in Wikis and understand their general nature. A “Wiki Warden” should be willing to help with the upcoming wiki migration to MediaWiki and have a vision for how our wiki should be organized and cleaned up. This person should be willing to do more work initiallycleaning up the wiki and then spend a few hours every week watching over activity in the wiki and gently steer the wiki into a direction of sense and overall usefulness.
  2. Documentation: This person should be working with the Wiki Warden (it could even be the same person) to coordinate the creation/maintanance of Wiki pages for use with our WikiDocs documentation system. This person should be have an overall vision for how to organize our documentation and to move from our current state to a more organized and useful documentation system for MusicBrainz.
  3. Trac: This person should be familiar with trac and work to remove the cruft that has accumulated in the bug tracker. We need someone to close old bugs that no longer apply, highlight bugs that are important and generally reduce the duplication present in the system. It would be best if this person could also take part of the weekly developer chats in order to stay in tune with the development process.
  4. UserVoice: While a lot of people have volunteered to take part in working with UserVoice, we need one person to take the lead and be in charge of the process. I would love it if this person could help us to settle on one of the proposed UserVoice workflows.

I’d like to stress once again that I am not looking for people to do a lot of work — I’m looking for leaders who can do a little work, but motivate others a lot of help out and create a thriving sub-communities that allow MusicBrainz to become more concise and cohesive. If you’re interested in one or more of these positions, please post to the comments.

Improving the MusicBrainz user experience: Would you like to help?

A few people have been commenting on how MusicBrainz has a few bugs that bother them on a daily basis, yet these bugs are never fixed. From a developers perspective its really hard to see which bugs in our large bug list really matter to end users — its hard to figure out which bugs should be fixed first. Rather than fixing the bugs that affect most people first, developers tend to fix the bugs that have the most insistent users shouting for those fixes. Unfortunately fixing bugs for overly vocal users may not be the same as fixing bugs that will improve life for the most people.

Warp suggested that we check out Get Satisfaction, while others suggested using UserVoice. Both of these services provide an intermediate layer between the developers and the end users to provide feedback about the bugs that are important to them. End users can enter the bugs that bother them and everyone can vote on those bugs/issues. While we already have a bug tracking system, this system is geared to the less technical users out there — not everyone loves entering bugs into trac. Plus UserVoice’s voting mechanism allows the most important bugs to rise to the top of the list.

I’ve explored UserVoice a little since they offer a free plan for Open Source projects. (Not to mention that their site is in Orange, which is a big draw for me. 🙂 ) It seems that it would be easy to integrate this with MusicBrainz. But, it seems that this is one more chore for someone to manage and the last thing I need is to take on another chore. I’m willing to do the technical integration, but I would need some help from volunteers to manage the day-to-day operations of UserVoice. I envision volunteers to pay attention to the data that collects at UserVoice and maintain a mapping between UserVoice issues and actual bug/enhancement tickets inside the MusicBrainz bug tracker. If you already play with trac and help us maintain it, this might be another aspect in which you could help MusicBrainz.

I’d like to know:

  • Is using UserVoice a good idea?
  • Do you see any potential problems in using it?
  • Would you be interested in being an Admin on UserVoice to help manage MusicBrainz’ UserVoice site?

Please let me know in the comments!

Calling all guinea pigs!

I come bringing good news! With the latest version of the server now out in the wild, we’re ready to move on to the next stage of MusicBrainz development. But first a quick refresher…

You may recall, many moons ago I (Oliver Charles aka aCiD2) began work on moving the mb_server codebase from our own in-house framework, to the tried and tested Catalyst framework – along with separating out the HTML into separate Template Toolkit templates. Well, after what seems like an age, it’s finally got to the time where I can start getting some critical feedback from the most important people – you!

As from now, test.musicbrainz.org is now running the development branch of this work. It’s important to realise that this new codebase currently has no javascript support. This decision was made because it’s very important we get the website fully functional, and then add bells and whistles on later. We’re starting from a mostly clean slate, so there’s a lot of chance of things breaking, and JavaScript was likely to be just one more headache.

Oh, and I’ve never deployed a server like this before, so please bare with me while I work out any problems running the server. I’m going to London tomorrow and coming back Saturday evening (slightly bad timing, I’m aware) – but I’ll do my best to check any messages that come my way!

However, before you jump straight in and overload us with work – I’d like to lay down some guidelines for providing us with feedback. This will (hopefully) ensure that we can see to these bugs as fast as possible.

Where to report:

Standard practice- report at our bugtracker – bugs.musicbrainz.org

What should you report?

The most important things to report are actions that cause errors to occur, invalid behaviour or features that are simply not available, but are from the main server. You should also report typos and other visual problems – but I will be encouraging people to help fix these themselves (more on this later!).

What information should you provide?

The most critical information is that you can provide us with as much context as possible. Please let us know:

  • Any steps to reproduce the problem
  • Whether you are logged in or not
  • The address of the page that caused the problem
  • As much information as possible from the top of the error page

The last point relates somewhat to Catalyst. Catalyst features improved error handling and can provide us with a stack trace. You should try and include this stack trace, and the errors at the top. Chances are, we’ll be able to reproduce this from the information you provide – but if not, the stack trace gives us one more pointer to where the problem is 🙂

How should you organise the report?

Generally speaking, just try to fill in as many of the fields as possible. I’ll be reading every single report that comes in, and re-filing it myself where necessary. Ideally, set the component to ‘MusicBrainz’, the milestone to ‘Server: TemplateToolkit’ and assign the bug to me 🙂

So…

Let the bug crunching begin!