#musicbrainz-devel

That makes parallel usage unreliable as too requests within 0.1s would give a failed response.

but people could still do it. but if we catch them, that is really bad for their business.

$1000 donation, sign up for a proper plan and you're back.

otherwise, go fuck yourself.

well, people can do lots of things to circumvent us at present anyway

Yes - and the license legalities would make the $5 for personal non-commercial usage only.

if your mission critical company is down, you'd open your wallet fast. :)

it's not like we protect the replication packets :P

ianmcorvidae: of course, but that doesn't use our resources.

note that github has very strict limits for unauthenticated access, which is somewhat related.

only some of OSU's

Exactly - they are paying for the web service not the data.

well, true

what I mean is that anything we do here has an element of trust

for sure.

so saying "hey, don't do that" and yelling at anyone who breaks it is pretty consistent with what we do elsewhere :)

And since you are using the same rate limiting mechanism as at present, just having two versions depending on whether you have a valid key or not - then the coding should be quick and easy.

ianmcorvidae: +1

ianmcorvidae: you're ok to work up the details on point #1 going forward?

ruaok: re: attaching to oauth (or whatever)? sure

My partner ran a pet food company. Credit card payments and shipments took 30 mins of staff time per order.

well, due diligence on the whole #1 bit.

okay

including a rough idea of how much it would take to implement this using stripe and not 3scale

well, defining "unlimited" or whatever we're doing will be the real challenge

I gave them a new web site where orders went simultaneously to dispatch and credit card payments - on the basis that you only took action to stop the shipment if the credit card payment failed.

I think in this context we're ok with assuming that there will be some constants for us to work with.

In other words, assume that customers are valid until you find an exception rather than be the security police.

which has been our model forever anyways.

okay

The Keep It Simple principle would seem to be relevant.

as long as I don't have to pull a Sprint and define the actual constant for "unlimited" or whatever we decide to call it, I can move forward :)

(telco picked at random :P)

And I like the look of Stripe.

ianmcorvidae: no such thing. we're going to be honest with our users. :)

haha, fair enough :)

anyway I think I'm set for that

and I'll ponder #2 less formally :)

ok, certainly collect questions for either/both.

and if roadblocks come up, drop me a mail.

what else is on your radar for us to talk about, ianmcorvidae?

I'd like to chat about ninja tune for a sec...

did you see the CSV file?

yes, I did. haven't poked it further yet

with the umpteengazillion columns?

I wonder if we should import it into a table and then query JSON out of it or write a script.

but I would very much like to get that imported into geordi soonish.

and do a blog post with it.

though stripe seem more expensive than e.g. braintree or chargify might be cheaper

ttfn

see, there is a bit of a stumbling block wrt to other labels.

ttfn

hm

no one wants to be the first one to flinch.

and now we have someone who said, fuck it, here is our data.

script probably is easiest, does it have any actual *ID* or anything?

so I want to make noise about that.

it looks like no

there are ISRCs and catalog numbers.

catalog numbers may do

yeah.

it may not matter, depending how likely we are to get updates to this :P

we are!

updates that aren't just additions?

I've added you to the data@ alias, which I've given to ninja tune for future updates.

yeah, I saw the alias

unsure.

ruaok: perhaps except more excel sheets in the future, so geordi should have excel support? :P

expect

*

eww.

but that is quite likely to be the case, sadly.

ninja tune don't normally deliver XML

erm

excel*

so they should be able to deliver XML

ha. we got a check from amazon.de. I bet that was mostly nikki's doing.

heh, the headers appear to be *wrong*

too bad I wasn't there to bring the check to the bank.

ianmcorvidae: they seem correct in the excel.

hm

lemme see

I didn't inspect the CSV. :(

New post: blog: Server Update, 2013-06-10 <http://blog.musicbrainz.org/?p=2000>;

I'm getting myself an actual thing for opening spreadsheets

much as I hate it, seems necessary :P

I seem to be missing "total parts"

from what I can figure out

that column is sparsely populated.

sometime is contains "1" (as text), not a number.

I've seen 2 a few times.

and some with "19" odd.

* reosarevok: Adding how tos to the menu

* reosarevok: area, not label

hm, something was being weird in looking at it, loading it in a real spreadsheet it seems fine

heh, combining artists with |

* mwtuea: MBS-6073: Inaccurate range of credits when grouped at the bottom of a release page

* mwtuea: Add test for MBS-6073

it does seem that their catalog numbers are good though

Oliver Charles: MBS-6364: Fix DuplicateArtists report now that comments cannot be NULL

ijabz: ping -- http://tickets.musicbrainz.org/browse/MBH-321 I'm thinking maybe can be fixed in the search server, would it be possible to make ?init=mmap finish serving any request currently in progress before re-initializing?

ijabz: as I mention on https://bitbucket.org/metabrainz/musicbrainz-se... we see a few ISEs in musicbrainz-server every time indexes get rotated because of the JSON stopping somewhere random in the middle

ianmcorvidae: presumably just having it finish serving requests does not solve the problem - the server is still in rotation while it's restarting, no?

i mean it does prevent it from serving half a response, which is definitely wanted

but people could still connect to a dead search server

sure, but an outright failure nginx will catch and route to the other one

I think

or do we HUP the search server, which blocks while it reloads indexes (queueing the connection)?

we call an endpoint on the search server

wget -O /dev/null 'http://localhost:8080?init=mmap'

is how we restart :)

ok

so not svc -d/svc -u

nope

ok

the search stuff is sorta weird, we have an MBH ticket for improving it

then whatever ?init=mmap does should cause the current requests to be finished, and any subsequent requests queued

my concern is I'm not sure how feasible running the loadbalancer from that process is

so, yeah, exactly that :)

(except asking ijabz, since I don't know enough about the search server to know how feasible and/or difficult that is)

Project musicbrainz-server_beta build #473: STILL FAILING in 11 min: http://ci.musicbrainz.org/job/musicbrainz-serve...

there, good wedge of PRs reviewed

warp, can you please merge those that have 2+ approvals?

(of your PRs)

you do

looks like yes! I'll do the same

whoo shipping things

* Ian McEwen: MBS-2782/MBS-2848: don't expand (in Add Medium) or show (in Edit Medium) artist credits where all changes are visible; also, condense and visually separate expanded display

* Ian McEwen: MBS-6296: don't show non-functional alias editing links for non-location-editors (or logged-out users)

* Ian McEwen: MBS-6349: s/\.tracklist// to display artist credits

* Ian McEwen: MBS-2782/MBS-2848: use whitespace for visual hierarchy

* Ian McEwen: Fix rollup replication to work properly alongside GPG.

ocharles: oh, did we release? I thought we were still in freeze.

ianmcorvidae hi, Im back

but only ruaok knows about how we rotate the indexes ectera

ocharles: shouldn't https://bitbucket.org/metabrainz/musicbrainz-se... be merged by now?

ijabz: it's done by moving them in, then calling init=mmap