We’ve finally released a new MusicBrainz virtual machine! This new version has become a lot more automated and is much easier to create and deploy. Hopefully we will be doing monthly releases of the VM from here on out.
A lot of things have changed for this new release. If you have used the VM before, you MUST read the instructions again. Before filing a bug or asking us a question, please re-read the documentation first!
Ready to jump in? Read the instructions.
This release features code from GCI student dpmittal, who fixed four of the tickets below under our mentorship. One of those tickets was for displaying the excellent artist icons that former GCI student (and current mentor) gcilou created. Those icons are displayed to the left of the name at the top of artist pages (examples: person, group, choir, orchestra, character, other). Nice work, gcilou and dpmittal! We also have various fixes and improvements thanks to chirlu and Zastai, listed below.
The git tag is
- [MBS-4159] – Vimeo relationship under the External links section
- [MBS-7009] – Exception if replication type is slave but no data in replication_control
- [MBS-8268] – Ratings (stars) display does not update on its own
- [MBS-9117] – CD Stub track count not serialized correctly
- [MBS-8359] – Add “Guess Case” function for Event names
- [MBS-8870] – Add Setlist.fm links to the sidebar
- [MBS-1352] – Different icon for Unknown/Person/Group on Artist pages
- [MBS-8542] – Blacklist Jaikoz from making barcode edits
The MetaBrainz ticket tracker (which, incidentally, received a long-needed upgrade recently – thanks, Gentlecat!) is an important tool for all of our projects. It collects all kinds of bug reports, feature requests and other tasks to be done and makes sure none are forgotten.
One of its auxiliary features is the possibility for users to vote for a ticket, to indicate which tickets they consider particularly important. (There are only upvotes; you can’t vote against a ticket.) This may factor in when MetaBrainz employees decide on which tickets to tackle next, although there are other factors as well such as the complexity and the impact of a particular issue.
In the past, who voted for which tickets has been private, mostly because that is the default setting in JIRA, the ticket tracker software used. Only administrators can see the list of voters for a ticket; regular users just see the number of votes.
Now, we have decided to change that: In the future, all logged-in users will be able to see who voted for a ticket. This should not be sensitive information; whoever expressed their support for a ticket by commenting on it instead of (or in addition to) voting already was in the public eye. Still, it is a policy change. We’ve therefore decided to wait two weeks before implementing the new privileges, in order to give everybody the chance to remove any votes that they don’t want to be known with. The ticket tracker provides a list of all tickets that you have voted for.
No major changes, but the “Infer track durations from associated recordings” option in the release editor has been removed for being circular and unsound, because recording durations themselves are automatically inferred from tracks. Thanks again to chirlu and yvanz for their code contributions. The git tag is
- [MBS-9102] – Age calculation attempted when there is not enough data
- [MBS-9136] – “Tracks with sequence issues” report is broken
- [MBS-9138] – Unnecessary double attempt at getting a Commons image
- [MBS-9140] – NewHost: Name of locale with territory does not replace locale code in UI language selector
- [MBS-9142] – Artist-Artist relationship editing dialog does not show up in French
- [MBS-7654] – Remove “Infer track durations from associated recordings” option
The Google Open Source Programs office is amazing!
In the past few years Google has sponsored our summit where we gather a pile of MusicBrainzers into one room and talk shop (and a bit of play) for a whole weekend. But, due to extenuating circumstances and our move to NewHost, we opted for a much smaller and lower key developer gathering in Barcelona. As a result we didn’t spend much money and I opted to not pester Google to support our summit as they have in the years past.
Then yesterday the lovely Cat Allman from OSPO send us a PO for $5000 and a stern reminder to send an invoice soon. After explaining the situation to Cat, she still felt it was appropriate to collect the money and to “use the money as best serves the project.”
Wow, thank you!
The question I have, for all of our readers, contributors, editors, hackers and advocates: How do you think we should spend $5000 to best serve MusicBrainz and its sister projects?
I’ll leave it wide open to everyone to chime in — feel free to put suggest anything reasonable and meaningful in the comments. Please do the skip the “send it to me!” type comments. 🙂
Finally, I want to thank Google for its continued support of our projects. Through its annual support of $40,000, Summer of Code, Code-In, the paid data license for its Knowledge Graph and the support of our summit, Google is the biggest supporter of the MetaBrainz Foundation. By far: Google has donated more than $366,000!
THANK YOU GOOGLE. Your support really helps us along!
This is our first release since the NewHost move, so it’s a mishmash of changes required for that and whatever else people submitted in between.
First, some dependency changes: memcached has been dropped as a dependency. We now use Redis as a cache, which had already been used for storing login sessions. In production we run two separate Redis instances: one as a cache (note: configure the DBDefs settings
PLUGIN_CACHE_OPTIONS) and one as a persistent session store (
DATASTORE_REDIS_ARGS). But it’s also safe (if less flexible) to use a single Redis instance without a
maxmemory setting for both, because cached entries will expire by default. So if you already had Redis running locally, you may not need to make any changes to your configuration.
This release also requires the Perl module
DBD::Pg to be version 3, which you may already have. If not, you can upgrade only that module with this command:
Thanks also to chirlu for upgrading reCAPTCHA on our registration page (which has hopefully reduced new spam accounts), Zastai for fixing some oversights in our JSON webservice, and reosarevok for removing the restriction on score URLs.
The git tag is
- [MBS-8762] – ISNI doesn’t appear on JSON WS
- [MBS-9035] – Coro dependency causes build failure on Perl 5.22 and newer
- [MBS-9091] – JSON WS: Aliases do not include begin/end date and ended flag
- [MBS-9127] – NewHost: UI language does not match “lang” in cookie
- [MBS-9132] – cannot add an alias (area)
- [MBS-9031] – Replace all usages of memcached with redis
- [MBS-9130] – Upgrade to new reCAPTCHA (version 2)
- [MBS-9096] – Upgrade DBD::Pg to version 3
- [MBS-9110] – Disable the score whitelist
I’m pleased to report that our nightmare of finding/reconstructing the missing replication packets is finally over!
Through many heroic hours of work, Bitmap and Chirlu have reconstructed the missing replication packets. All clients should now be on their way to being up to date. We’ve learned a number of lessons (some good, some bad — that’s life, right?) in this ordeal and we hope to avoid these issues in the future.
An integral part of this recovery process were a number of people from our community who helped us: Users mbcz, rembo10 and xeam sent us their complete DB dumps! Bitmap used these to sanity check and diff several other database to finally extract the missing packets. Thank you for dropping what you were doing and sending us a few GB of data over blazingly fast connections. Without you this would not have been possible; and this is not an exaggeration. Thank you!
After some more rest we’re going to continue to put out smaller fires that remain from the move to NewHost, but for now, the big fires are put out. Just in time for the weekend!
In the 11 year history of the replication stream we’ve had to have users restart their stream about 3-4 times because of problems on our end. Zero would’ve been nicer, but I’m proud that we’ve been able to make this system work for so long. On a daily basis we seem to have about 400 replicated copies of MusicBrainz running all over the world. Clearly this part of our service is well used and I sleep a little better at night knowing that our most critical data is backed up across the globe.
Just for fun, here is a graph of the replication API usage over the last 6 months:
Towards the end the graph shows the week plus long break, then a small blip as some of our replicas got unstuck yesterday and the much larger spike shows the rest of the replicas getting unstuck. Now, as to what caused the blip in mid-October — I have no idea.
Anyways, please accept my apologies for the replication stream outage and keep replicating!