Development update: search fixes, release locking and tagging

I’ve been busy hacking on all sorts of projects for the MusicBrainz server in the past few weeks. Fall is a nice time where the business world slows down as people prepare to hunker down for the holidays and the weather turns more temperamental. That’s the perfect time to get some hacking done!

The projects I’ve been working on are:

Search fixes:

Yesterday Lukas started a new branch to fix a number of pressing bugs related to the search features. Unbeknownst to him, I had already started hacking on the lucene_index and lucene_server projects to bring about more search features and to fix nagging bugs. Besides fixing issues like the less-than-perfect search result ranking and unaccenting, I’m also adding support for searching annotations. Given user feedback related to FreeDB searching (or the general lack of a decent FreeDB web search) I’ve decided that our search server can handle the addition of searching for FreeDB CDs that can be imported to MusicBrainz.

Theses search fixes/improvements will eventually (in the next few weeks) be rolled out as a server mini-release, rather than waiting for the next full server release that brings about many new features and thus will require an extensive testing cycle. If you have some must-fix bugs that you want to see fixed in the upcoming mini-release, post a comment with the bug number that needs fixing. We’ll see what we can do — the rest will have to wait for the next major release. Remember, I can be bribed with good chocolate. 🙂

Once I do a few more hours of work, I will point you to a server where you can play with these new features.

Release locking & Voting improvements:

I’ve started work on creating the release locking system. The idea is to create three strictness levels (loose, normal, strict) where changes to a album will require few, the usual or more votes to make changes. The strictness level depends on if an album is locked and how many subscribers the albums has. This feature will also bring about a system where every edit type will have a defined voting duration, number of unanimous votes required to pass, action after expiry (keep open, remove, accept) and wether or not an edit type is an autoedit. These will be defined for each strictness level, which should give us much more control over tuning how various edit types will behave.

The voting improvements will take into account your feedback from this blog post. The general idea with both of these features is to tune the editing/voting system so that we can optimize the work that editors do. Right now the system is too rigid and applies the same rules to all edit types, which makes the system more cumbersome than it should be.

Please read the release locking wiki page and give us some feedback about this feature!


An enthusiasic user (Chris Ovenden) recently sent me mail expressing interest in adding social tagging (folksonomy) support to MusicBrainz. I mentioned to him that Keschte, Yalaforge and myself hacked the beginnings of this feature out when we met up in Germany 18 months ago. I’ve dusted off that old code and updated it for the new layout of our pages. I’ve also finally taken some time to set up the test server so that we have more than one test sandbox running on it. If you care to take a look at the very incomplete tagging features, go to the tagging sandbox at . You will need to log in and then go to an artist, album or track. The header for each of these entities will have a new pink box that allows you to attach a tag to the entity. You can click on the tag to see what other entities have this tag attached to them.

What’s still needed:

  • View your tags you applied to entities
  • JavaScript improvements to make the tagging UI more intuitive and pretty
  • Remove tags
  • A script to aggregate user’s tags and apply them to general tags that everyone can see, even those who are not logged in
  • Consider who this will affect our database server before we roll this out. We may need to get a separate DB server for this feature.
  • Consider the privacy implications — should we allow the world to see what people tagged files with or only the aggregated data? Make it an option?

Technorati Tags: , ,

6 thoughts on “Development update: search fixes, release locking and tagging”

  1. Ticket #2254 asks for the adition of a new release type. I am not sure if you can put this into the mini-release, since it might affect customers.

  2. Zout:

    I will back-port all the fixed bugs. What other not-yet-fixed bugs are show stoppers?

    I am planning on reviewing any outstanding web service and searching bugs and try and nail as monay of those as I can in this mini-release.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.