Server update, 2015-09-07

The 2015-09-07 server update is released today (a day late). Late because I wanted to investigate a fix for cover art uploading, which many people have reported issues with lately. Notwithstanding troubles at the Internet Archive, the server should hopefully give less errors now when uploading.

The other changes deal with edit-system bugs and URL cleanup enhancements.

Thanks to Gentlecat and reosarevok for their work on today’s release. The git tag is v-2015-09-07 and the changelog is below.

Bug

  • [MBS-8531] – Delete release label edits with no label fail to display
  • [MBS-8532] – Can’t edit a release label to add a label
  • [MBS-8533] – Catalog number-only release label edits no longer show in a MB Label’s edits
  • [MBS-8543] – Error uploading image: MalformedPOSTRequest

Improvement

  • [MBS-8124] – Recognise and clean up Loudr.fm URLs
  • [MBS-8182] – Improve Deezer URL cleanup

Roman Tsukanov joins the MetaBrainz team

I’m pleased to announce that last week we officially hired Roman Tsukanov, AKA Gentlecat to be a part time developer for MusicBrainz!

Gentlecat has already established himself firmly in our community: Last year he rocked the CritiqueBrainz project for Summer of Code and this summer he rocked AcousticBrainz. And he’s written our shiny new MetaBrainz web site! He is now in the process of learning perl and has started to help Bitmap review existing code reviews. And he has even fixed a couple of issues already. In other words he lives up to his name: To Gentlecat something means to rock it!

I’m quite happy to have such a capable developer participating in MusicBrainz. Welcome to the team Gentlecat!

August Community Revisit

Ohoi m’hearties, it’s time for the first monthly Community Revisit, where we’ll revisit what happened in MetaBrainzLand during the last month. Ready for the ride? Leggo!

The primary thing happening this month has likely been the changes in the MetaBrainz employee line-up following Ian’s departure in July. In the beginning of the month, Freso (wait, hey, that’s me!) was pulled on board as Community Manager (a brand new position for MetaBrainz too!), and just at the end of the month, GSoC wonder child Roman “Gentlecat” Tsukanov was hired as the new software engineer. So hi to us two! 🙂

Speaking of GSoC, the Google Summer of Code, this year’s edition is also fast coming to an end, and our four students and their projects are closing up and giving their work the final touches to have them ready to go live. Don’t be surprised if you hear more about these projects soon.

One thing that did go live during August, in no small part thanks to Ben “LordSputnik” Ockmore and Leo_Verto: the new IRC chat logger! Chat logs from IRC are now available at http://chatlogs.metabrainz.org/ – the site still needs some MetaBrainzifying, but Ben has done a great job of importing (pretty much) all the old chat logs to the new system and the bot is running in all the official MetaBrainz channels. If you’re on IRC (or you just like poking at the IRC logs), be sure to say “Thank you!! <3” to LordSputnik and Leo_Verto next time you see them around!

Another person who has made a mark in the last month was Alex a.k.a. caller#6, starting up the discussion about the current situation of MusicBrainz’ Area entities. Be sure to check out that blog post and let your voice be heard, if you don’t feel like it’s being represented already. The next instalment should be out before long.

We also had two server updates (pretty much all bug fixes) and an updated Virtual Machine image was finally released for the more tech oriented people.

This about rounds off the August Community Revisit. What do you think about the format? Did I miss any important community happenings? Any other comments? This is a brand new venture, so nothing’s set in stone yet!

From Denmark with love,
Freso

There will be no autumn 2015 schema change

Schema changes are always a lot of work for us and we end up spending much time preparing for it and then even more time cleaning up/catching up after it. As a result, some critical non-schema change features keep getting pushed back… to the point that we never get to them.

To try and break this cycle, we’re going to skip the Autumn 2015 schema change. Instead we will focus on other tasks such as hosting and community features.

We will resume our schedule with the next planned schema change around 15 May, 2016. After that release we will determine if we want to go ahead with 1 or 2 schema change releases a year.

Server update, 2015-08-24

Today’s release contains only bug-fixes. We’ve fixed an issues with “downvoted” tags being lost after a merge, and made release label edits more robust when the related releases or labels are merged. The git tag is v-2015-08-24 and the changelog is below.

Bug

  • [MBS-3867] – Edit release label fails prerequisite when labels are merged
  • [MBS-8462] – Webservice can create tags with upper-case letters
  • [MBS-8505] – Up/down vote for tags that contains uppercase letters updates a lowercase version of that tag
  • [MBS-8515] – Can’t edit or add entities related to an URL
  • [MBS-8516] – Relationships used as documentation examples can’t be merged
  • [MBS-8517] – Internal server error loading /ws/2/collection?fmt=json
  • [MBS-8518] – Edit release label edits get stuck after the release is merged
  • [MBS-8524] – Merging entities can corrupt tags up/down-votes
  • [MBS-8528] – Trying to search for an example to add to a relationship type gives “Lookup failed: Not Acceptable”
  • [MBS-8529] – compile_resources.sh: Error: ENOENT, no such file or directory ‘/home/i18n/musicbrainz-server/po/javascript.<lang>.po’

Server update, 2015-08-10

This is mostly a bug-fix release, with one important note for people running their own server:

A longstanding issue with versions of MooseX::Role::Parameterized greater than 1.02 has been fixed, and now version 1.03 or greater is required. If you’re using cpanm as INSTALL.md suggests, running cpanm MooseX::Role::Parameterized will get the latest version. If you’re using the new VM, sudo apt-get update; sudo apt-get upgrade will install the latest packaged dependencies from our PPA repository.

Thanks to all who contributed to today’s release. The git tag is v-2015-08-10 and the changelog is below.

Bug

  • [MBS-8495] – Lieder archive has moved to lieder.net
  • [MBS-8498] – Entities in a collection not mergeable
  • [MBS-8499] – Entities in a collection not removed when empty
  • [MBS-8501] – Work edit form is broken because document.currentScript is not available in all supported browsers
  • [MBS-8502] – Cookies are no longer persistent
  • [MBS-8507] – Duplicate checking code can prevent editing existing entity
  • [MBS-8514] – Work credits’ AC cannot be removed nor edited

Improvement

  • [MBS-2477] – Relationship edits should track merges

New MusicBrainz server virtual machine available

Time to check the weather forecast for hell, because it appears to have frozen over! We have finally released a new Virtual Machine that contains all of the MusicBrainz server software and fixed all of the currently outstanding bugs (for the VM).

The new VM now uses a 64-bit architecture and has 80GB of disk-space so it should be much easier to get along with. I tried to ship one VM that has the search indexes build in, but after 3 hours (and increasing time) of trying to export that VM I killed it. If someone has better luck exporting a VM after building search indexes, please let me know. Also, VirtualBox seems to have improved in stability on Mac OS, so we are not going to build a VMWare version of the VM at this time.

All the details for the new VM are on our Server Setup page.

Remember to get your Live Data Feed access token here if you plan to use the replication.

Server update, 2015-07-27

Today’s release improves the way series are automatically ordered (MBS-7557), and fixes a few bugs in the edit system preventing certain edits from closing. We’ve also got some fixes and additions to the URL cleanup code.

Thanks to all who contributed to today’s release. The git tag is v-2015-07-27 and the complete changelog is below.

Bug

  • [MBS-8308] – Non-redirecting Weibo URLs are changed to URLs which redirect
  • [MBS-8475] – Allow links to Amazon Mexico
  • [MBS-8480] – Home page “latest posts” garbles fancy punctuation coming from the blog titles
  • [MBS-8483] – Entities that require a disambiguation comment ISE if submitted with relationships
  • [MBS-8484] – Server does not fully collapse spaces surrounding non-printable characters
  • [MBS-8485] – ModBot can’t close deletion edits if the entity no longer exists
  • [MBS-8488] – ModBot can’t close an AddISWCs edit where any of the works were deleted
  • [MBS-8490] – Works with no relationships not being deleted
  • [MBS-8491] – Work merges aren’t happening

Improvement

  • [MBS-7557] – better series automatic ordering
  • [MBS-7987] – Event series should be (auto-)ordered by date
  • [MBS-8457] – Remove “?oldformat=true” from Wikipedia URLs

New Feature

  • [MBS-8312] – festivals from songkick and setlist.fm not allowed as event-relationships

Task

  • [MBS-8487] – Add autoselect to soundcloud for series

Poisonous people

As I work to re-shape our community, I’ve been brushing up on open source philosophy. I’ve already mentioned “Producing Open Source Software” book, which is great, but can be somewhat dry at times. A more recent book that covers more of the team related issues is the excellent “Team Geek“. In particular the chapter on “Poisonous people” is really well worth reading.

One passage summarizes some underlying themes of my current series of blog posts:

“But there’s a danger here. In general, it’s not healthy to spend one’s time stewing in an ocean of negativity—it tends to eat you up and can create more conflicts in the long run. The term poisonous person is a nasty label and automatically creates a dividing line between “us” (the good guys) and “them” (those nasty jerks). There’s a better way to think about the problem. Instead of running your team as an elite fraternity with a mission to repel mean people, it’s healthier to create a culture that simply refuses to tolerate certain negative behaviors.”

Our community currently has a number of disrespectful people who could be classified as “poisonous”. However, I have good news for these people: I’m wiping the slate clean! Everyone gets a fresh start. As of today no one is poisonous! Hooray! \ø/

However, if you decide to go against the updated principles I’m stating in this blog post series, you should expect that people will confront your behaviour. One point of these blog posts is to provide bite-sized chunks of information that can be used to succinctly state updated project policies. If you encounter a person who is communicating aggressively, is being disrespectful or is hindering the community from moving the project forward, please remind them of these blog posts. When you encounter a problematic person, post the link to this blog entry and respectfully remind them to improve their behaviour.

I would also like to propose that we organize a group of volunteers to form what could be called: “Team Respect“. If someone in the community finds a person who is going on a “no-vote spree” or is entering useless and aggression filled tickets into jira, then they can call on Team Respect to jump in. Team Respect should engage this person, link to the relevant blog posts/project policies and remind them to be respectful. The team should also review the actions of the person — if the team feels that the actions by this person were uncalled for, the team should work to counter-act their actions. For instance, if someone goes an on unjustified no-vote spree, the team members should evaluate the edits in question and if they “improve the database” then they should vote yes on the edits, improve the edits to remove the objections or even approve the edits outright if they are auto-editors. Use your best judgement, of course!

The basic idea behind Team Respect is to make being a disrespectful person no fun and frustrating. At the same time Team Respect can raise positive feelings in the community by working together and protecting the work for polite, respectful people. And the polite, respectful people whose work was protected will be more inclined to contribute in the future.

Transparent communications

In the past few months I’ve tried to re-iterate that MusicBrainz is an open source project and that open source projects should carry out their work in public whenever possible. I received quite a bit of push-back every time I suggested this, so I feel it necessary to reinforce this concept.

I’ll reference the “Producing Open Source Software” book and in particular the Chapter 2:

Even after you’ve taken the project public, you and the other founders will often find yourselves wanting to settle difficult questions by private communications among an inner circle. … All the obvious disadvantages of public list discussions will loom palpably in front of you: the delay inherent in email conversations, the need to leave sufficient time for consensus to form… The temptation to make decisions behind closed doors and present them as faits accomplis, or at least as the firm recommendations of a united and influential voting block, will be great indeed.

Don’t do it.

If this sounds familiar to you, it should. Sadly this has been happening inside our community for some time. I am now going to put my foot down and insist that communication about the project happen in public. Since I will be setting the dev tasks and will be working to establish a rough road-map for the project, I’ll know what level of communication is appropriate for the current tasks at hand. And I’ll be watching for signs of this improving!

I am going to set an example and keep my communication visible to the public if at all possible. Some things are private matters (pay, personal issues) that should not be discussed in public and I will not discuss those in public — there is no change for private topics. But for all other topics, I am going to insist that we discuss matters in a public channel where the community can follow along. So, if you send me a private message in IRC or a direct email, expect me to ask you to move the discussion to a public forum if the communication really doesn’t need to be private. As a guideline, I would expect about 98% of the project communication to be public.

In the coming weeks I am going to define the various roles that people hold in MusicBrainz and then document them on the spiffy new MetaBrainz web site. If you plan to take on any role in MusicBrainz (or any of the MetaBrainz Foundation projects) I will require that your communications be transparent. Please keep this in mind as I work to bring some clarity in the project.

I would really recommend to everyone that they read all of Chapter 2 linked above — it makes a lot of solid points that are very important to our project right now.