We’ve talked a bit about our upcoming schema change release, but we hadn’t nailed down the exact date of the release. Now that we’re tangibly close, we’ve settled on the May 15th as the actual release date.
As some of you may know, this summer through Google Summer of Code I’m working on internationalization of musicbrainz-server. As outlined in my proposal, I’m currently looking to find what I call “language liaisons”: folks willing to be the go-to person about a given language for me and other developers.
Auf Deutsch!
What’s expected of liaisons:
Willing to be pestered occasionally, by me or other developers, about language-specific concerns: when adding new features, and thus adding new strings, we’d like to be able to ensure nothing’s added that will need to be changed before it can be translated into a given language.
Willing to file bugs for strings already in the database that are untranslatable, should you find them.
Be on the musicbrainz-i18n mailing list; this will be the main venue for organization and communication about i18n issues.
Ideally, to be an active translator for your language – but this isn’t a requirement, because I’d like to get the widest global coverage I can; even if a language doesn’t currently have a translation, we don’t want to unintentionally sabotage future translators with untranslatable strings!
日本語
I’ll also be determining a (related) list of “target languages” for the summer, with the intention of releasing translation on musicbrainz.org with these languages at the end of the summer. I’ll consider for inclusion on this list languages that are both in active translation on Transifex and have language liaisons.
If you’re interested in being a language liaison, please contact me: ianmcorvidae (at) musicbrainz (dot) org, editor ianmcorvidae, or ianmcorvidae on IRC, and join the mailing list.
We’ve released another set of bug fixes and improvements for the server. Thanks to Joachim LeBlanc, Johannes Weißl and the rest of the MusicBrainz team for helping on this release!
Bug
[MBS-2553] – Change wording for no External Links in the sidebar
[MBS-4041] – Nonexistent elections cause Internal Server Error
[MBS-4544] – Predefined advanced searches on /search no longer work
v4.0.1 of libmusicbrainz4 has now been released. This is primarily a maintenance release to fix a couple of bugs that were reported. Additionally, the code has now moved to GitHub, and can now be found at https://github.com/metabrainz/libmusicbrainz.
The main changes are:
Fixed bug LMB-30 – Unable to access all relation lists on objects with multiple relation lists
The interface has changed as regards to retrieving relation lists, due to LMB-30. Previously, the library only returned the last relation list that was returned in the XML response. The old ‘RelationList’ method on the Artist, Label, Recording, Release, ReleaseGroup and Work classes has been marked ‘deprecated’, and a new ‘RelationListList’ method will return a list of all relation lists for the entity.
For backwards compatibility, the ‘RelationList’ method will operate in the same manner as release 4.0.0, only returning the last relation list.
As ever, please see the enclosed README for details on support and bug reporting. The release is available for download at http://musicbrainz.org/doc/libmusicbrainz.
Sorry for being a week behind on this release, but we’ve just finished pushing out another set of changes. Many thanks to Lukáš Lalinský, Paul Taylor and the rest of the MusicBrainz team for making this release happen! Here’s what we’ve just released:
[MBS-3160] – Add view to artist pages that shows release groups/recordings/etc credited to that artist only (solo releases only – exclude collaborations, feat., etc)
Earlier today we switched the latest release of our search server live. Paul says:
In this new release of the search server the basic search will now search more fields and return variations of what you searched such as spelling mistakes and the scoring has also been improved. Advanced search now lets you search for when a field doesn’t exist and you can do exact searches that take accent characters into account using the new accent fields.
We’ve also upgraded to the latest version of Lucene, added a way to see how scores are calculated for results and added integration tests. Hopefully this will all help with future stability.
UPDATE: This code lives in svn and can be found at r13480. I’ve also created this tag.
Thanks for your hard work on this release, Paul. And also thanks to Ollie for taking time to push the server portions of this live today. Here are our release notes:
As per my previous blog post, today is the deadline for submitting tickets for consideration in the May 15 2012 schema change release. Eleven tickets have been championed for this release — you can see each of these tickets in the schema change release fix version in jira.
I would like to call your attention to three tickets that I think ought to get more input from the community:
If any of these issues interest you, please take a look and leave a comment if you have any input. Finally, I will be keeping track of the progress of the schema change release on this wiki page.
I’m hoping to put together a complete schema change document that outlines the exact changes to our schema on April 2.
Many thanks to all of the volunteers who adopted tickets and are moving them forward!
We’ve just finished pushing out a new server update, that addresses a few minor bugs. We initially planned to roll these changes in with the release of our Cover Art Archive, but sadly this project needs a bit longer. Many thanks to Johannes Weißl, Wieland Hoffman, Ian McEwan and the MusicBrainz team for their work on this release.
Bug
[MBS-3897] – Missing space in template for ARs w/disambig
[MBS-4291] – Default install looks for compiled js/css.
[MBS-4368] – Release editor: track parser is broken
[MBS-4383] – Statistics page is showing "Active Last Week" stats twice, leaving out "Edited Last Week"
[MBS-4399] – Medium titles not displayed when attaching a discid to a medium
[MBS-4403] – DBD::Pg::st execute failed: ERROR: new row for relation "recording" violates check constraint "recording_length_check" at lib/Sql.pm line 396
For our last schema change release we had a ton of issues around which tickets we should address and which ones were properly defined for us to work on. I’d like to make this a lot more clear for the next go round; here is what we’re going to do:
Starting today and for the next two weeks, we’re going to seek people to be the champion (sponsor) of a ticket. If you feel strongly about a schema change ticket getting taken care of, you should consider championing this ticket. Once you’ve decided to do adopt a ticket, you should assign the ticket to yourself.
Then, over the next two weeks it will be up to you to do the following:
Derive consensus around the core concept of the ticket. If you go through the process of working up a ticket, but no one agrees with what you’re proposing, you’ve wasted your time. Make sure that you get buy in from others in the community. For instance, if Nikki doesn’t like it, chances are its not going to fly. 🙂
Ensure that the ticket clearly states what needs to be done to implement the ticket. The ticket should essentially become or link to a requirements document. This requirements document should explain what the new feature should do. It should not explain how it should be done — we should leave the how to our developers who are going to implement the feature.
Provide as much supporting documentation as you can. Mock-ups for UIs are deeply appreciated (even if they delve into the how realm of things) and very useful for meaningfully discussing these tickets.
Have the ticket reviewed by a developer for clarity and completeness, then address any issues said developer may raise.
On 19 March, we’re going to look at the list of tickets that people have taken on and choose the ones that are clear enough to move forward. If you’ve done all the work outlined above, the chances are good that your ticket will be chosen to move forward. If your ticket is chosen to move forward, there will be more questions that the developers will raise — hopefully those can be tackled in the space of a week. After that we will take all of the well defined tickets and schedule them for implementation. All the other tickets that are not clear to implement will be rejected and will have to make another pass though this process in the autumn.