This update hopefully fixes some issues with “Edit Medium” edits that, in rare cases, resulted in an incorrect track listing. Sometimes tracks were being inexplicably deleted. The git tag for today’s release is v-2016-02-08.
Bug
[MBS-8752] – Database inconsistencies when updating medium
[MBS-8765] – instrument_annotation should not be backed up in mbdump.tar.bz2
In an effort to get our JSON Web Service out of “beta” status, we’ve made some backwards-incompatible changes to it in this release:
The video flag on recordings is now outputted as true or false instead of 1 or 0.
Empty relations arrays are not outputted for linked entities anymore, since linked entities never include relationships.
The iso_3166_1_codes, iso_3166_2_codes, and iso_3166_3_codes properties have been renamed to iso-3166-1-codes, iso-3166-2-codes, and iso-3166-3-codes, respectively. This only applies to lookup and browse requests; search requests already outputted these with hyphens.
The iso-3166- properties mentioned in the previous point are not outputted if they’re empty.
Some other changes to the web service have been made, but are considered additions (not changes to existing output), so hopefully shouldn’t cause any problems. You can review them in the changelog below.
Other Changes
An issue where entities deleted from the database (but still present in the cache) remained visible has hopefully been fixed. There are several other miscellaneous bug fixes linked below. Thanks again to Ulrich Klauer for his contributions. The git tag is v-2016-01-25.
Bug
[MBS-5676] – JSON relationships output doesn’t include target-type
[MBS-6166] – Deleted accounts can still have details edited
[MBS-7241] – Non-transactional cache means the cache can sometimes fail to delete entities that are gone at the database level
[MBS-7735] – ws/2: recording’s “video” flag inconsistent between xml and json
[MBS-7921] – Internal server error when requesting /ws/2/isrc as JSON
[MBS-8367] – ws2 JSON incorrectly returns non-included field as null value
[MBS-8396] – JSON output has no ordering key attribute for release group series
[MBS-8563] – Release & Release Group browse requests without type/status filters return results which contradicts the documentation
[MBS-8688] – Random tagged entity type display inconsistency in personal tag page
[MBS-8722] – Edit stuck trying to change the gender of a group
Our first release of 2016 consists mainly of data-display fixes by Ulrich Klauer and a couple small improvements by Google Code-In students Caroline Gschwend and Ohm Patel. Notably, internationalized domain names are now displayed in decoded form: https://musicbrainz.org/url/2de1616a-7ca0-4688-92cc-0a8373190ede
Thanks once again to the above contributors. 🙂 The git tag for today’s release is v-2016-01-11 and the changelog is below.
Bug
[MBS-4575] – Old add release label edit does not display
[MBS-5205] – Text diff incorrectly highlights first word that didn’t change
[MBS-7844] – Name variation marker not used for artists in tracklists in “edit medium” edits
[MBS-8012] – Release dates/countries are displayed strangely in edit release label edits
[MBS-8161] – Medium titles have no diff highlighting when displaying edits
[MBS-8210] – Multiple “Remove ISRC/ISWC” edits on one page interfere
[MBS-8330] – Another name variation check after HTML entity conversion
[MBS-8413] – Removed URLs in edits are badly encoded
[MBS-8692] – Expired Catalyst sessions remain (partially) in Redis
[MBS-8698] – Content negotiation for JSON-LD representation does not work with multiple MIME types in Accept header
Improvement
[MBS-6407] – Add username to our verification mails
[MBS-8683] – Display internationalized domain names in decoded form
[MBS-8709] – Mark up removed entities as usual in add medium/edit medium edits
[MBS-8713] – Block SoundCloud search and tags URLs
So today it is a month ago since the Google Code-in competition started and 18 days until it is ending. I wanted to take this opportunity to talk a bit about some of the things that have happened so far and where we’re at.
Since December 7th when Google Code-in started, we have been in touch with 107 students on the Google Code-in site, of which 70 have completed at least one task and thus earned a digital certificate from Google. 11 students have so far earned themselves a t-shirt from Google by completing 3 or more tasks. The student with the highest number of completed tasks right now sits at 17 tasks, followed by one at 16 and another at 15 completed tasks. The student with the 10th most tasks completed has 3 tasks to their name.
Stanisław Szcześniak, GCI student from Poland, presenting about MusicBrainz.We have had 7 students do presentations on MusicBrainz in at least India, Romania, England, and Poland; about 50 reviews written for CritiqueBrainz with a few more in progress; a couple of MusicBrainz how to’s written for the wiki; one video tutorial made (which hasn’t been uploaded yet); a bunch of tests written for BookBrainz; updated and have had made a bunch of icons/logos in various places; a bunch of code patches and tests written for almost all our projects, as well as for beets (a 3rd party music file tagger and organiser heavily using MB data).
We have also had to report 3 students for plagiarising leading to their disqualification. 🙁 However, compared to the amount of work and number of students, I think it’s a decently small number.
Overall, I am (still!) really excited about MetaBrainz finally being a part of Google Code-in, and I definitely think the lack of sleep the first week and newbie questions on IRC and on the GCI tasks are worth it. We’re getting some great stuff done, that we may not have gotten around to in any reasonable time ourselves, and we get to help all these students learn about programming, open source, open data, licenses, and a bunch of other things. I’m happy and I’m not looking forward to picking only 5 finalists and only 2 winners. There are definitely more than that I would personally like to see in both categories. 🙂
Have you had any experiences with or thoughts on our Google Code-in participation so far? Please do share them with us in the comments!
The edit listings for your subscribed entities (and subscribed editors) now shows all edits entered within the past 7 days, by default (so, auto-edits are now visible, plus edits that may have passed by vote before you saw them). There’s a new toggle-able option on the page to only display open edits, to restore the previous behavior while voting. We’ll hopefully introduce some way to mark closed edits as reviewed/dismissed soon, to make the listings easier to digest.
Edit histories for large collections should hopefully load a bit faster now. Please comment on MBS-8368 if you have a collection that still consistently times out when viewing its edit history.
We’ve also made a slight change to our release process. Previously, our master branch was our “stable” branch which pointed to the most recent release (i.e., the code we run on musicbrainz.org itself). If this is what you expect, you should now be using the production branch instead. The master branch has become our main development branch, which means it may be slightly less stable from now on (of course, we’ll do our best to avoid that).
Thanks to Ulrich Klauer (chirlu) for his contributions to today’s release.
The git tag is v-2015-12-14 and the complete changelog is below.
I am pleased to announce that I’ve just hired our first person responsible for looking after the day-to-day business operations of MetaBrainz! Christina Smith, a Canadian who also lives in Barcelona, has signed on as our part-time Business Development Guru (/Manager/Troublemaker/What have you).
This marks a significant step forward for us in a number of ways. First, it acknowledges that we have grown enough to warrant such a position. Second, Christina will improve how we communicate with customers and how much revenue we bring into the foundation. In the last two years we’ve added several new projects, but haven’t been able to hire new engineers to work on these projects, so hopefully having Christina will allow us to grow to support our new projects as well.
Christina’s responsibilities can be summarized as:
manage relationships with our supporters
provide timely, friendly and helpful answers and solutions for our supporters
increase revenues by connecting and building relationships with current and potential supporters
general accounting tasks including invoicing and payment tracking
periodic research, recommendations and help to address evolving business needs. (e.g. research the implementation of a company presence in Europe, including help in setting up a new headquarter in Barcelona)
research and suggestions on law and policy issues related to the business
I am super excited that Christina will be working with us — this removes a pile of tasks off my plate, which should allow me to focus more on running the foundation and managing our teams.
For the remainder of December, Christina will work on research tasks on how we can establish a better base in the EU. Then in January she will properly join the team and be present in our IRC meetings.
Today we’ve released several changes decided at the recent MusicBrainz Summit:
German, French, and Dutch translations are now usable on the main server, via the language menu at the top right of any page. Previously these were only accessible on the beta server. Don’t forget to help contribute on Transifex if you find any issues in the translations. You can also help translate some of the less-complete languages over there.
“Add relationship” edits have been made auto-edits for everyone. By a recent calculation, only 0.78% of these have been canceled or voted down, yet they make up a large percentage of our open edits and are easy to remove.
“Add release” edits have been made auto-edits for everyone. Since releases added to MusicBrainz are available immediately through the website and web services, there’s no telling where the MBIDs are being used. Permanent and reliable IDs are a core tenet of MusicBrainz, so duplicate releases should always be merged to avoid MBID loss, not voted down or deleted. I’ll be looking at ways to better detect duplicates during the add-release process, though.
“Add release label” and “Remove release label” edits have been made auto-edits for everyone. Like the previous two edit types, release label additions are among the most common types of open edits, and are rarely canceled or voted down. Release label removals are also easy to revert because all of the removed data is contained in the edit.
UPDATE 2015-12-03: It was neglected to mention here that “Edit release label” edits were also made auto-edits, since they are equivalent to a removal plus an addition. For statistics, see the comments at MBS-8666.
In addition to the above changes, Roman Tsukanov has added some new reports, and we’ve fixed a few editing bugs.
The git tag today is v-2015-11-16 and the complete changelog is below.
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.
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.
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.