Tag Archives: Development

Picard 2.0 dev available via PyPi

Sambhav’s GSoC project is all about Picard 2.0, and among progress made the devel version is now installable via PyPi: https://pypi.python.org/pypi/picard_dev

To install the dev builds you need to have a Python 3.5 or greater. At the moment it is mainly a port of 1.4.x to Python 3 and Qt5, with support for HiDPI and new icons !

Please note that Picard Dev version uses a different config file than your stable Picard installation. As such the settings and plugins will be on their default configuration.

To use your stable config with the dev version, simple copy your “Picard.ini” file from your MusicBrainz user folder to “Picard Dev.ini” which can be found in the same folder.

Since testers may want to run a stable 1.4.x version along the 2.0 dev one, the executable is named “picard_dev”.

Of course, we encourage people to test this version on every platform they can, and report any issue.

Thanks to Sambhav Kothari for the fantastic job he did on this ! And stay tuned, more to come !

Sandbox upgrade and downtime: Tuesday, 24 November, 2015 @ 17:00 UTC

Tomorrow, Tuesday, 24 November, 2015 at 17:00 UTC, we will be bringing down rika, our sandbox server, to update the operating system. We expect this to take approximately two and a half hours, during which time rika will be updated to Ubuntu 14.04 LTS. If you are running any services (such as a MusicBrainz sandbox) on rika, remember to back up your data (like the MOTD says!), and be aware that you will need to restart these services once the server is available. Thank you for understanding the brief inconvenience as we put shiny new things in place.

UPDATE: Unfortunately, something has gone wrong during the update process. rika is responding to pings, but no services have come up. We will do our best to resolve this quickly, but there is currently no ETA.

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.

A positive outlook going forward

My next installment of MusicBrainz management changes focuses on how we should frame our discussions going forward. Currently there is a lot of animosity in our community and a lot of finger pointing — neither of these are constructive for moving forward, so I will aim to cut these short and focus on fixing rather than blaming.

I’d like to offer an analogy to start this discussion: When two people are in a personal relationship and when that relationship starts falling apart, a lot of negative feelings come up. The two people will often blame each other and be convinced that the other person is the reason for all of their troubles. If you’ve ever had an opportunity to talk to two people in a failing relationship, you’ll probably have seen that failing relationships are usually the fault of both people. I’ve yet to find a relationship that failed, solely on the actions of one person alone. Both people are involved, both people had a hand in it.

That said, I’ll step forward and say it: I am guilty. I am partially to blame for what is going on. Go ahead, feel free to blame me for the troubles we’re facing.

But, that is it. Basta! We’re not going to engage in finding every little thing that was done wrong, by whom and work hard to lay blame. That is pointless and it brings up unnecessary emotions. Instead of finding blame we’re going to find problems to our solutions and we’re going to move forward.

As part of me restructuring MusicBrainz, I’m going to be asking everyone what problems they perceive with the project right now. I will listen to the problems, catalog them and attempt to build a plan for tackling these problems in the future. However, I will insist that problems are stated without aggressive communication (e.g. passive aggressive communication) and without value judgements. If you cannot state your issue without being aggressive or disrespectful, you can count on me calling you on your behaviour. I will not address problems that are stated in an aggressive or disrespectful manner.

For instance, it is not acceptable to say: “I don’t think that anyone is going to listen to me anyway, but I think that because of Joe’s idiotic decision to not allow white space in code, all of our code is a freaking mess — this was the worst idea ever!” This statement has passive aggressive communication, it lays blame and contains a value judgement. One way to express the same concern in a constructive manner could be: “The decision to exclude whitespace from our code has created a number of difficulties for people to follow our code. We should re-consider this decision.”

This means of expressing problems, ideas and solutions allows us to focus our energy on moving forward and improving the project. It avoids painful discussions that won’t gives us much insight on moving forward. As we work to mend our community, I will be relying on these communication tools heavily. If you run afoul of these new communication guidelines, expect me to remind of you of this blog post. 🙂

Restructuring MusicBrainz’ management

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:

  1. 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.
  2. 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!