In the recent past, the MusicBrainz community has become more fractured with evident tension rising between members of the community, the dev team and myself. I’ve been struggling with trying to find a good way to fix these problems and I’ve attempted making a number of changes over the past few months. Mostly with mixed or bad results, which further increased the frustrations for everyone involved.
While I was on vacation the past two weeks, I had some distance from work and at random points during this vacation a few key issues/solutions became clear to me. Over the next few weeks I will be announcing changes to how I manage this project and possibly some changes to some of our core policies to support these changes. Stay tuned on this blog for more announcements regarding this restructuring.
In the first round of changes, which I will detail in a subsequent blog posts, I would like to:
- Re-emphasize that we are an open source project and that we must do all of our work in public. Point 3 of our social contract states: “We won’t hide problems and policies: We will keep all MusicBrainz related discussions open for public view at all times, regardless of their content. All problems and policies related to MusicBrainz will be visible to all.” As problems in our community grew, factions hid from the public view. A lot of development work and development discussion went underground in private communication channels that had no transparency at all. Fixing this will be my most important goal moving forward.
- Take control of tasking the development team. Starting this monday, during our weekly development chat, I will take the lead on discussing what tasks the development team should be focusing on. I will need to catch up on a lot of happenings that I haven’t paid attention to recently. I also suspect that we will need to talk quite a bit about which tools we would like to use to manage our short, medium and long term plans. Don’t expect us to magically revamp this process on Monday — Monday will simply be the first step in what could be a long journey to improve how the MusicBrainz dev team is currently managed.
More posts are coming in the next few days!
Thank you for your feedback from the last round of logos! The most important messages that we received from the last round were:
- The colors were too saturated
- There logos contained too much detail and when made smaller, would not look good
Nico, our designer from Monkey.Do, has taken this to heart and come up with the next round of logos. In this iteration, he is demonstrating progressive details with a logo: At the lowest level of detail the brain is just the split hexagon as suggested by Aerozol, and as the logo gets larger, more detail appears in the logo.
Have a look:
As usual, we’d love your feedback!
I’m pleased to announce our upcoming schema change release on 18 May, 2015. In this release we will implement each of the tickets listed in this fix version:
- MBS-1347: Implement aliases for release groups, releases and recordings.
- MBS-4145: Up/down vote for tags — This feature will be our first attempt at getting into “genres”. People have expressed that our tags are vaguely useful for genres, but expressed frustration at not being able to give feedback about the tags. Voting on tags will allow us to find the tags that people find useful, which will allow us to develop a list of tags that we consider to be “genres”.
- MBS-7489: Artist Credits for Relationships — This feature will allow MusicBrainz to store an alternate artist display name (Artist Credit) for a given credit (Advanced Relationship).
- MBS-8266: Make medium titles VARCHAR NOT NULL — Fixes a database inconsistency that should have little to no impact on end users.
- MBS-8279: Remove empty_artists etc. database functions — Another database/code refactoring that should also have little impact on end users.
- MBS-8283: Remove DB constraint that disallows empty event names — This allows event names to be blank, since many events do not have a proper name.
- MBS-8287: Log deleted entities that were in a subscribed collection — This feature will give users a notification if one of their subscribed entities is deleted.
- MBS-8302: Add Live Data Feed access token support — Add support for using access tokens. See below for more details.
UPDATE: We forgot to list the following change, which is already almost ready to go – apologies for the slightly late addition!
UPDATE 2: This change will not affect users of our replicated data at all, since the changes are to non-replicated tables. This is the only reason we decided to sneak this change in after the official announcement.
- MBS-8004: Extend collections to other entities — This extends the current ability to create collections (user-made lists) to other entities apart from releases and events. That means users can make arbitrary lists (“Artists I’ve seen live”, or “Songs I can play on the piano”), and also subscribe to them to get notified when anything on the collection is being edited.
Finally, I’m not describing MBS-8278, since that is an internal housekeeping reminder and will not really affect downstream users. All in all this is fairly light schema change for us, since we currently have a number of other projects that we wish to undertake in the medium term.
Important Live Data Feed change: After 10+ years of our Live Data Feed being available to anyone on the honor system, we are going to require Live Data Feed users to have an access token to fetch the replication packets for the Live Data Feed.
At the beginning of May we are going to release a new MetaBrainz web-site that will allow all of our current Live Data Feed users to create an account and to generate themselves an access token. Non-commercial users and existing commercial users will be immediately approved and will receive an access token. This access token will need to be add to your MusicBrainz-server (or mbslave) configuration in order for the Live Data Feed to continue to work as expected. Any new commercial users will need to sign up to one of the support tiers that the new web-site will present.
NB: If you are currently using the Live Data Feed legitimately, you should see no disruption to your use of the feed.
For the past week we’ve been battling a variety of hosting issues from search servers acting up, gateways dropping packets and now our database server freaking out for no particular reason. We managed to fix/mitigate the issues in the first hiccups, which is good. And for three days everything looked peachy. Then, out of the blue our database server did this:
You don’t have to understand much about hosting computers to understand that this is bad. Out of the blue our server started having to work much harder than before. Normally that means that something using the server has changed. We’ve looked for a traffic increase — we can’t find one. We’ve examine someone being abusive to us — we found a couple users, but blocking them didn’t change anything. We tried turning off non-essential services that make use of the database server, but nothing ever changes. We’ve restarted the database server. We’ve slapped this, we’ve poked that, we’ve prodded, undid and tested just about everything we can think of. But, the load comes in spikes and recedes again; over and over.
We’ve had amazing help from a number of people, but several skilled computer geeks with a support from lots of others haven’t managed to make a dent in things. We’re exhausted and we need a bit of a break. So, that’s what we’re doing for the next 7 or so hours.
Then at 15h PDT, 18h EDT, 22h UK, 23h CET we’re going to start to upgrade to the latest version of Postgres 9.1. We hope to be down for less than half an hour — but you never know. We’ll tweet about the downtime and put up a banner on the MusicBrainz site to let people know when exactly we’ll take the site down.
Sorry for the hassle — we’re all amazingly frustrated right now — please bear with us.
A day late with putting this out, due to some sleep mis-scheduling on the part of yours truly, but we’re back with another release! This release includes a variety of small bug fixes and improvements, as well as a reworking of the track parser, which now supports a more complete set of options to control exactly which information is parsed and which is updated in the tracklist. Thanks to bitmap, chirlu, ianmcorvidae, nikki, and reosarevok for their work on this release!
The git tag for this release is
Full list of issues in this release:
- [MBS-7753] – Username displays wrongly on area pages
- [MBS-7799] – unable to add artist as database entry
- [MBS-7800] – Last.fm URL cleanup doesn’t work for .br and .com
- [MBS-7804] – URL cleanup for places doesn’t validate links to Discogs or Other Databases
- [MBS-7805] – series-rels inc parameter doesn’t work since WebServiceInc was not updated
- [MBS-5925] – Show whether you’re subscribed to a collection on the collection overview
- [MBS-6705] – Move “No linguistic content” lyrics language from “Other” to “Frequently used”
- [MBS-7270] – The option to parse vinyl track numbers can be confusing
- [MBS-7749] – Rap Genius is now Genius
- [MBS-7797] – When editors are not referenced in the DB, delete their rows entirely rather than renaming to Deleted Editor #N
- [MBS-7798] – Release relationship editor needs a loading indicator
- [MBS-7803] – Add reports for entities with annotations
- [MBS-3730] – Feature parity: Please re-add the ability to parse only times
- [MBS-3732] – Feature parity: Please re-add the ability to parse only titles
- [MBS-4921] – Add a [No lyrics] option to works language
- [MBS-7785] – Update ESTER to account for the merger of its branches
As some of you with slave databases may have noticed, we made a slight error and excluded some of the new tables from our schema change in replication (tracked by MBS-7603).
Luckily, the tables in question are presently quite small, meaning that if we act now we can add them without needing a formal schema change release (by simply replicating out the changes). Less luckily, this process requires taking some very heavy locks on the ‘series’ database table, so we’ve chosen to have a small amount of downtime to run the script, at (or shortly after) the time mentioned in the title, which also gives us a chance to restart our database server to incorporate some extensions we’d intended but failed to add during the schema change release last week.
We don’t foresee this process taking more than a few minutes, and no action should be necessary for downstream data users.
We’ve finally settled on a date for the MusicBrainz summit in Copenhagen this fall: September 26-28, 2014. Save that weekend if you’re interesting in attending — we will post more information to the summit wiki page once we get closer to the event.
Looking forward to seeing you in Copenhagen.