#musicbrainz-devel

CatCat: most likely there is

:D

now i willnot have a problem with squeesign in my sleeping bag

ianmcorvidae: I notice it was your birthday yesterday (your TZ), so: Happy belated birthday! :)

However, your home page is out of date now.

yup :) thanks

oh, bah

I always forget about that :P

*g*

Oh

Happy birthday then!

Or unhappy, depending on your opinions on getting old :p

somehow I can't categorize 23 as 'old' :P

Tell that to your 10 year old self!

And while you're out (better to combine trips, save fuel) stop by http://web.mit.edu/adorai/timetraveler/ and say "hi". I'll be there (though I might be pretty old).

Judging by the colour-coding on the language comparison matrix, the case is between Java and Haskell?

honestly I suspect python will actually win, if we switch at all

the coloration isn't exactly super-careful

and three levels doesn't totally capture the nuances

haskell has a big problem with being perceived as scary

and Java the main team has little experience with, which is more important than it seems from the coloration

uk: do you favour haskell, or not java? :p

We could do a short introduction to Haskell at the summit. :)

the reason java and haskell look really good is that they have people very specifically trying to argue for them (ijabz and ocharles respectively)

reosarevok: Both, I guess. ;-)

the problem is more for people new to the project

with perl we already have the problem of people going "ew, perl" and thus not contributing

haskell could easily amplify that problem

I think the main problem isn't the language, but the code structure.

At first, you have no idea where to look for a specific piece of functionality.

with haskell? the problem is neither, it's the world's perception

Not with Haskell, in general. Current code base too.

ah

If I want to fix X, I first need to know where to look.

what's amusing to me about that is this is the most intuitive codebase I've worked with :)

in terms of module organization

there are a few things that annoy me periodically but largely not

Well, if I don't know TT, Catalyst and Moose, it's quite a barrier.

Completely apart from Perl.

that templates are in root/ is one of my gripes, though once you know it you know it and that's done

in my experience for smaller stuff Moose is usually irrelevant other than you end up calling its methods obviously

and Catalyst is just MVC, the only vaguely-weird thing is our Entity vs. Data split (at least for me)

worth noting that when I came to this codebase I'd never written any perl, much less anything else (I was a python/common lisp person)

I actually didn't want it terribly hard to find the place for the one small thing I needed to fix. Not when I actually went and looked properly at the source code and wasn't being lazy...

*didn't find

CatCat: I'm trying to do some lobby work to bring MB summit to DK next year.

ruaok: search indexes on master seem to have something going a bit funky -- http://musicbrainz.org/artist/5a77d365-056a-45d... isn't appearing in search results but it's been around ~12 hours

ruaok: beta is fine

(to be clear: it isn't appearing in search results for "Belle Histoire", which is its name exactly)

murdos: btw, your live updater doesn't seem to update the last-updated date that the search server reports -- beta's showing 2012-10-01 11:10 UTC, which is older than some of the artists I see in the results :)

ianmcorvidae: ah. I might comes from the search servlet not refreshing its cached information. could you create a ticket in jira? I won't be able to take a look at this issue before a few days

murdos: sure, can do

murdos: made ticket, it's assigned to you :)

ianmcorvidae: Update translations from transifex.

ocharles: since the ticket is assigned to you, what will happen for the cover art table, given that we'll suddenly be replicating a table that already has info in it? is the upgrade script going to handle that?

(and if not, how *do* I upgrade rather than reimport?)

hello!

moin moin warp warp

ianmcorvidae: seems that indexes are not rotating properly

I just kicked them by hand.

but, that speaks volumes of the new setup. if it fails, it seems to fail for a short time and then recover

yup

what was the issue with the indexes not rotating?

also, do we have a schedule for switching back to the new search server release? got things shipping that'll use it on the 15th :P

still investigating the not rotating cause.

and once I get that stable, I'd be willing to try the latest release.

warp: ping

k

ack

ruaok: pong

is there still a need for rotating indexes to hobbes?

no

ok.

murdos' updater performs good enough eventually.

thats awesome to hear. :)

it takes a few rounds of indexing to catch up with the replication packets

well, you've seen the graphs. I haven't checked since, but I don't expect any changes there.

right.

I wonder how to boostrap a new index.

how frequently are we doing full builds for the beta stuff?

if for some reason we need to build a new index.

(I know I'm seeing oct. 1 on beta, but I don't know if that's the last build or some caching thing)

I guess we would need to stop replicating while those indexes built.

Mon Oct 01 17:59:47 UTC 2012FINEFinished updating index: recording in 5231.0 seconds

ouch.

that one is the longest, because we've turned stuff off while releasing.

the subsequent rows are:

how many packets?

Mon Oct 01 18:49:11 UTC 2012FINEFinished updating index: recording in 999.0 seconds

Mon Oct 01 19:46:15 UTC 2012FINEFinished updating index: recording in 822.0 seconds

Mon Oct 01 20:38:03 UTC 2012FINEFinished updating index: recording in 326.0 seconds

the busiest during normal operating since then:

Tue Oct 02 13:50:09 UTC 2012FINEFinished updating index: recording in 1058.0 seconds

good.

hmmm.

what is the index updating procedure for schema changes?

ruaok: 6 packets? is that correct? seems to have been turned off for about 6 hours.

seems workable. :)

ruaok: if if that question was for me, I don't have the answer. I know little about the search server, I just know how to run this stuff.

yep, that question was for you. :)

seems that we need to figure that out before we deploy it.

or we just don't deploy this until after the schema change release :)

the two may need to be upgraded in lock-step.

that for sure, but we need to make sure we dont screw ourseelves may 15 2013

anyway, for this updater, you can always just rerun the normal indexing once to recreate a starting point. and start murdos' updater afterward.

ianmcorvidae: > @40000000506bd32c3338637c svc: warning: unable to control /etc/service/jetty-service: access denied

that would be it.

the search user has not perms to restart a service.

heh, that sounds problematic

well, jetty does run as user 'jetty', not 'search', yes?

yes, but daemontools might require root perms

I think this is a case for sudo

after sleep.

sleep 8h; sudo something

bullshit am I making haskell 'fit'. It's a good language.

nikki: i'm afraid I'm not sure how to handle that yet

I tend to agree, but I do think haskell and java look good because their rows were mostly filled out by people who like them

anyone can edit those rows

I'm not saying it was intentionally filling it out to look good in some manipulative way, I'm just saying they got filled out by people who like the languages :)

ocharles: how about making the upgrade script dump the newly replicated tables if it's running on a master server (i.e. one that makes replication packets), put the dumps on ftp and make the upgrade script import them on slaves

so that they're at the right point for replicating

i think that's the only way to do it

luckily, it's a single small table, so I think that's reasonable

and yeah, I agree re: CAA replication, otherwise it's an annoying synchronization task

I guess it should also truncate the table before trying to import it too, since people like me already imported some data into it

yea, I was about to say

it might be better if we nuke the table, then add everything into the first replication packet

are you sure you won't get told off for making huge packets? :P

but that packet will probalby be too big because 500kb is still a lot of data, somehow.

:)

it's an approach worth testing, anyway

its somehow big in the same way that you believe haskell to be mainstream enough for our purposes.

well, that one's not one that could be done more efficiently, unlike the statistics packet

it's also a lot fewer row changes, so could be fine

we will do a normal dump and re-import