MetaBrainz Foundation Community Blog
We’ve just added a page that documents what we’re currently blocking on our Web Service. We hope to lift the block on python-musicbrainz/0.7.3 tomorrow and instead throttle the number of requests it can make in a given period of time.
I’ll post another entry once we’re done with making those changes.
It seems that there wasn’t nearly enough consensus about the schema change release as I had expected. We’re going to skip all of the tickets, with the exception of the MBS-3693 ticket.
This really makes the January 12 release a mini-schema change release. Should be quick and painless. 🙂
One of the issues raised at the last summit was that our customers could use more time to prepare for schema change releases, since they require engineering effort on their part. In an effort to meet our customer’s needs we’re going to a set schedule for schema change releases. Going forward we’re going to have two schema change releases per year: On or about 15 May and on or about 15 October.
We’ve picked these two dates as dates that have the least amount of impact from holidays and people taking holidays. Most companies have normal working schedules around these dates, which should allow companies to dedicate the required resources to handle our schema changes.
However, we have one significant change that we need to push out on a more timely basis than May of next year. For that reason we’re going to plan a one-time exception to our new schedule for 12 January 2012. You can see the tickets we’ve scheduled for release in January in this schema change milestone.
We’ve already created release versions in Jira for all of the schema change releases in 2012. As we go through the year we’re going to add tickets to that milestone. Of course, we’re going to make lots of noise as these schema change release dates approach. We’re going to post a list of tickets that will be included no later than a month before the release.
Any questions? Ask them in the comments!
We’ve just updated our search server with the latest changes and bug fixes!
This update to the Search Server finally solves the search for artist “!!!” problem properly, should now be able to find just about any artist, release, etc that contain any crazy character combination. Also you can now search for number of releases in release groups and artists with unknown gender. The code base has now been updated to Lucene 3.4, which was the latest available when these changes were made (its at 3.5 now).
Thanks for your hard work on this Paul!
Another update has just gone out, a few days later than planned. This is mostly a bug fix and minor improvement release. Sadly, when deploying the update we broke the release editor for anyone who was editing during the server switches – something we didn’t anticipate. Sorry! Here’s what’s changed:
In an effort to bring the community into our development process more, I (ocharles) have built a new little application to help the MusicBrainz community decide exactly what we should focus on. I present to you, the Scheduling Game!
The idea behind this little application is to let the community quickly scan through open issues and decide when they believe they should be fixed. Each editor is presented with 3 options:
Later, when issues have been voted on by enough people, the developers will try and decide how to schedule work to best fit the needs of the community.
A few disclaimers… Firstly, this is just an experiment! We don’t know how well it will work, though initial testing has shown it to already be quite useful. Secondly, it’s not really much of a game, but I wanted to give it a cute name (I know how picky everyone can be!). Currently only a subset of open tickets are available for voting on – specifically tickets in the “NGS + 1” and “Post NGS” milestones on JIRA, as these milestones are in need of a sorting.
The scheduling game is currently live on my server at http://scheduling.ocharles.org.uk/. You can have a look at the current (anonymous) votes at http://scheduling.ocharles.org.uk/results. If you have any questions or comments, you can reach me in IRC as ocharles or email oliver@musicbrainz.org. Happy voting!
A few days behind on this one, but we’ve got this release out. This release has one controversial change, which I want to discuss in this blog post.
A lot of people want this, and we’ve shipped something that adds this functionality. However, a lot of people think this is too verbose, and to a point I agree – there’s a lot of information there that can be displayed better. However, work on this issue has been on and off for almost the past 2 years. We’ve got a solution here that while far from ideal will get this ball rolling.
This is an unpopular move on my half, but I’m asking users to please try and bear with us until the next release (scheduled in for 5th December), which is just over a week away. Hopefully having this fairly messy display so open will raise enough discussion on how exactly to move forward. If you really must see it gone, you can use AdBlock or user styles in your browser to hide the dl.ars element.
It’s been a while, but we’ve finally got a new server release out! This one didn’t go perfectly smoothly, and we had (more, i’m afraid) troubles with the release editor. We’ve got a fix for this out, so editing should be at least as stable as it was before. As always, please do continue to report any bugs you find. Here’s what’s changed:
An application that uses our python-musicbrainz/0.7.3 client library has been putting undue load on our servers all at once. This application looks up something at MusicBrainz at 03:00UTC causing our servers to be overloaded at that time each day.
To protect our servers from being overloaded we’re going to block this application from 3:00 UTC – 4:00 UTC. We’re hoping that this will alllow us to identify the application and start a dialog with the application authors. Once we have established communication with the authors and worked up a plan to fix this, we’re going to release the block.
We really dislike blocking applications, but if applications are being inconsiderate of our resources, we’re left with few options. We hope to hear from the application authors soon so we can resolve this issue. Also, we’re moving forward with our plans to require User-Agent strings that properly identify applications using our service to fix this problem going forward.
If you are the author of said application, please leave a comment with information on how we can get in touch with you.
In an effort to mitigate/fix MBS-3379 we need to restart the service that keeps the session information for our release editors. We’re going to do that tomorrow Saturday October 28 at Noon PDT, 3PM EDT, 8PM London, 9PM Amsterdam. If at this time you have a release editor open, submitting your edits will fail and you will need to start your edits over again.
Sorry for the inconvenience.