#musicbrainz-devel

I would think that'd just be format: cassette.

(bootleg cassette)

alastairp: Anyway, approved. I don't know how urgent it is for you to use it, but with 4+ yes's, there's no need to wait 50+ minutes to have it applied. :p

;)

thanks

one thing we're not sure about how to do is if we should be giving a 'latinised' version

(Of course, if you don't use the WS, you'll still need to wait the ~50 minutes for the next replication package... ah well. :))

as another psuedorelease with exactly the same data? with aliases?

don't bother?

yeah, we use our own server

alastairp: If you don't need it, don't bother.

are edits applied before the replication packet is generated? or would we have had to wait 2 hours for both to happen?

OK

alastairp: I think the replication is run once ModBot's run is finished.

cool

Hence why some packets finished 10+ minutes after the hour at one point last year, before ModBot's code was optimised.

(Or maybe I misremember something.)

actually, maybe we do need the latinised version. since we'll be showing both on our app

we'll think about it

we don't have aliases for releases, so a pseudo-release is the only way to provide a transliteration if you want one. if you don't want one, there's no reason you have to add one, if you do, there's no consensus on whether it should have all the data or only provide the tracklist

interesting points!

transliteration. that's the word I was looking for

OK. when Moha is back we'll talk about it

I'm personally in favour of only providing a tracklist, since we have a relationship things can (and should!) use to get the other data and duplicating it means maintaining two (or more) copies of all the data just so that someone can avoid requesting the data from the non-pseudo-release version

but that's just a tracklist

how would you do artist names? aliases?

Aliases, yeah.

Since artists *can* have aliases.

I was referring to things like dates, countries, labels, catnos, urls, things that don't actually change between the original and the transliteration

for the artists, some people use artist credits, some just use artist aliases, I'm undecided there :)

using artist credits does make some sense, since artist names can vary and we don't have any way of grouping aliases

on the transliterated release?

yeah

track [x-latin] performed by [y-arabic] credited as [y-latin]

well, where "performed by" refers to the track artist, since we don't have artist credits on relationships :)

bingo. thanks. we'll discuss it

yes. of course

Guys, keep getting error when building from git [at github.com]:metabrainz/musicbrainz-server.git (schema-change-2014-05): https://gist.github.com/UmkaDK/d1fa01287e3976b0...

that branch doesn't require me upgrading to schema 20, does it?

I would assume that the schema change branch requires the schema change, yes.

Are we putting a banner up that the site is going down for the upgrade?

we plan to, yes

kepstin-laptop: I do know what you mean :) ... but the lib/DBDefs.pm.sample still has "sub DB_SCHEMA_SEQUENCE { 19 }" in it...

UmkaDK: that probably won't be changed until the release is ready

either that or it's an oversight

I seeee... ok, thanks! I guess I better go and update my schema then!

kepstin-laptop: thanks for the heads up!! :)

yeah, you definitely don't want to upgrade it until replication stops with some error about mismatched schema versions

you'll want to wait until after the schema change release is done, then run replication up to the point where it stops due to the schema change, then do the code upgrade and migration.

Ok... thanks everyone!!

instructions for doing this have been typically sent out as a blog post within a few days of the schema change release :)

(usually right after, I think?)

ye, the last few times it pretty much straight after the release...

yeah, after the fires are down to a smoulder. :)

:)

Happy 1400000000 unix time to you all

)

:)

ijabz1: ping

/ws/2/instrument/?query=flute&offset=0&max=25&fmt=json&dismax=true => 400

heh, I should probably deploy the servlet to jetty for that to go better. :)

hmmm. didn’t help.

ruaok ping

Is it just instruments failing (assuming indexes built) or different stuff, if so what different stuff ?

ruaok: ping

ruaok, ianmcorvidae: I updated PR with revision stuff. It would be nice if you could take a look

I hope I got all that SQL right

I’ll have a look now, Gentlecat

ianmcorvidae: you around yet?

ruaok: I should probably note that I tested it locally. Always doing that.

man, I’m tired. today was a long day.

there is too much scheduled for later, I better do it now.

ok, looks ok to me.

ruaok: thanks

I think I'll wait for ianmcorvidae to come back and take a look before merging

I think that is a good idea, but I suspect that him and I and I are in the same boat wrt to free time

ruaok: Should we add a banner up now about the downtime tomorrow?

we usually put the banner up when the update window opens.

so more like 20 - 60 minutes notice.

Okay

I'd say it wouldn't hurt to put it up with a longer notice, like 12 or 24 hours... but that's just me.

(Esp. since we know about it well in advance and it's not a "OMG-everything's-burning-and-exploding-and-wtf-is-going-on-there-is-this-about-to-melt??" situation.)

and then everyone is going to whine about the banner being up for so long

the banner is up too short! </whine>

(people always whine about everything)

Why a banner at all? We can read about it elsewhere! </whine>

Ian McEwen: Add packaging for search too.

bitmap: I added another comment to the Series UI PR. :) In any case, the link phrase thing should go into the schema change branch asap, I think.