IRC log of musicbrainz-devel on 2012-07-03

Timestamps are in UTC.

00:00:45 [ianmcorvidae]
no idea what that other thing even is :P
00:10:41 [reosarevok]
A drug
00:10:46 [reosarevok]
Also known as minecraft
00:18:56 [kepstin-laptop]
* kepstin-laptop notes that firefox correctly supports multiple opensearchdescriptions things on one page.
00:19:43 [kepstin-laptop]
* kepstin-laptop still wants unified search anyhow.
00:27:24 [dvon]
dvon has joined #musicbrainz-devel
00:46:50 [MiX-MaN]
MiX-MaN has joined #musicbrainz-devel
01:44:30 [ruaok]
ruaok has joined #musicbrainz-devel
03:03:20 [kurtjx]
kurtjx has joined #musicbrainz-devel
05:43:06 [ruaok]
ruaok has joined #musicbrainz-devel
06:05:25 [outsidecontext]
outsidecontext has joined #musicbrainz-devel
06:27:30 [warp]
hello!
06:28:54 [warp]
time for reggaeton and json
06:31:11 [mayhem]
morning warp.
06:31:23 [mayhem]
I didn't realize mayhem was available now. :)
06:32:18 [warp]
freenode did a massive nick cleanup a few weeks ago.
06:32:26 [mayhem]
bonus. :)
06:32:40 [mayhem]
i can has moar consistency
06:32:42 [warp]
register and link it!
06:33:29 [warp]
when will we do a nick cleanup on musicbrainz.org? :)
06:35:33 [mayhem]
I did. :)
06:35:37 [mayhem]
when should we?
06:35:39 [mayhem]
10 years?
06:36:53 [warp]
I guess we should first start keeping track of when a nick was last used
06:37:16 [warp]
(i.e. last login / site visit)
06:37:34 [mayhem]
we have that
06:37:53 [warp]
ah, it's not exposed musicbrainz.org/user/<name>
06:39:21 [warp]
+at
08:08:43 [plaintext]
plaintext has joined #musicbrainz-devel
08:15:37 [djce]
djce has joined #musicbrainz-devel
08:40:52 [reosarevok]
reosarevok has joined #musicbrainz-devel
08:55:58 [Freso]
Freso has joined #musicbrainz-devel
09:33:35 [jdamcd]
jdamcd has joined #musicbrainz-devel
10:11:16 [underscor]
underscor has joined #musicbrainz-devel
10:37:55 [kepstin-laptop]
kepstin-laptop has joined #musicbrainz-devel
10:57:22 [kurtjx]
kurtjx has joined #musicbrainz-devel
11:01:59 [djce]
djce has joined #musicbrainz-devel
11:12:46 [ocharles]
ocharles has changed the topic to: http://musicbrainz.org/#devel | Agenda: text column constraints (ocharles)
11:12:52 [ocharles]
joy, my topic in the last meeting was completely missed
11:13:00 [reosarevok]
huh
11:13:04 [reosarevok]
Yeah, was going to say
11:13:08 [reosarevok]
That was there yesterday :/
11:13:12 [reosarevok]
Hmm
11:13:22 [reosarevok]
I guess everyone who actually cares will be here tonight though
11:13:26 [reosarevok]
Maybe we can discuss it?
11:13:50 [ocharles]
sure
11:22:36 [MBJenkins]
Project musicbrainz-server_beta build #1: FAILURE in 25 sec: http://ci.musicbrainz.org/job/musicbrainz-server_beta/1/
11:26:08 [MBJenkins]
Project musicbrainz-server_beta build #2: STILL FAILING in 1 sec: http://ci.musicbrainz.org/job/musicbrainz-server_beta/2/
11:26:58 [ocharles]
yay, code review is down
11:31:29 [MBJenkins]
Project musicbrainz-server_beta build #3: FAILURE in 0.7 sec: http://ci.musicbrainz.org/job/musicbrainz-server_beta/3/
11:38:31 [icrazyhack]
icrazyhack has joined #musicbrainz-devel
12:07:19 [MiX-MaN]
MiX-MaN has joined #musicbrainz-devel
12:23:50 [MiX-MaN]
MiX-MaN has joined #musicbrainz-devel
12:25:51 [Swarup]
Swarup has joined #musicbrainz-devel
12:27:06 [bitmap]
bitmap has joined #musicbrainz-devel
12:36:04 [Swarup]
Hi ..we're noticing intermittent socket read timeouts from our mb api servers..mostly seems queries against /release-group such as /ws/2/release-group?artist=73090692-6257-490e-8f14-10343ce3a55b&offset=0&limit=100
12:36:25 [Swarup]
any suggestions?
12:38:21 [djce]
djce has joined #musicbrainz-devel
12:39:20 [bitmap]
bitmap has joined #musicbrainz-devel
12:42:20 [MiX-MaN]
MiX-MaN has joined #musicbrainz-devel
12:50:48 [bitmap]
bitmap has joined #musicbrainz-devel
12:50:59 [ocharles]
search server happy?
12:51:30 [ocharles]
oh, hmm, that url is not a search server one
12:51:45 [ocharles]
and you increased your process count?
12:52:19 [rembo]
rembo has joined #musicbrainz-devel
12:53:14 [rembo]
hey guys - i'm trying to rebuild my search server indexes, and i'm getting this error:Exception in thread "main" org.postgresql.util.PSQLException: ERROR: relation "release_group_type" does not exist
12:53:24 [rembo]
what's the best way to update my database?
12:53:45 [ocharles]
your database is up to date, your search server isn't
12:53:56 [ocharles]
you should pull down the latest search server code
12:54:13 [rembo]
and then just rebuild the indexes?
12:54:43 [ocharles]
yea
12:55:19 [rembo]
awesome - thanks
12:55:58 [rembo]
congrats on the google moneys btw!
12:56:33 [kurtjx]
kurtjx has joined #musicbrainz-devel
12:57:08 [ocharles]
yes, thanks to google for that one :)
12:58:18 [kurtjx]
kurtjx has joined #musicbrainz-devel
12:58:51 [Swarup]
ocharles..do u have any suggestions on the socket read timedout that we get intermittently..our timeout is set to 2 secs..and most of the time it returns within that limit..but other time it times out..mainly happening for /release-group queries
12:59:13 [ocharles]
2 seconds is a really fast timeout
12:59:21 [ocharles]
can you up that?
12:59:25 [ocharles]
we use 30 seconds at MB
12:59:43 [ocharles]
do the time out urls consistently timeout?
13:00:00 [Swarup]
no..only intermittently
13:00:52 [ocharles]
not so sure about that i'm afraid
13:01:01 [ocharles]
do you have a powerful database machine?
13:01:05 [ocharles]
maybe it's overloaded there?
13:01:40 [Swarup]
yeah db side i know is real powerful one..16cpu one..but i can ask dba to monitor it
13:01:41 [ocharles]
you could enable query logging and see if there are slow queries
13:02:06 [ocharles]
running the server with SQL_DEBUG=1 will also produce SQL logs
13:02:09 [ocharles]
(with timing)
13:02:27 [Swarup]
but it's not a consistent issue..which is where i'm not real sure..if it's slow query..it should fail every time ..right
13:03:12 [ocharles]
not necessarily
13:03:24 [ocharles]
depends on what the db is doing, where locks are, what's in ram, etc
13:03:34 [Swarup]
ok
13:05:39 [djce]
djce has joined #musicbrainz-devel
13:22:45 [djce]
djce has joined #musicbrainz-devel
13:23:26 [Swarup]
ocharles..our Ops are trying to capture slow logs..but can't locate php-fpm.conf file so not sure where that configuration is but we should be able to do: <value name="request_slowlog_timeout">5s</value> <value name="slowlog">logs/slow.log</value> 9:20 or i'm guessing: request_slowlog_timeout = 5 and slowlog=logs/slow.log
13:23:45 [Swarup]
how can we configure that in nginx or mb server
13:24:11 [MBJenkins]
Project musicbrainz-server_beta build #4: STILL FAILING in 4 min 10 sec: http://ci.musicbrainz.org/job/musicbrainz-server_beta/4/
13:25:11 [ocharles]
Swarup: eh? i meant query logging in postgresql with log_min_duration
13:26:36 [Swarup]
yeah i got that..but Ops wanted to capture logs on mbserver side using nginx that takes longer..wanted to know if you guys have any idea..
13:26:48 [ocharles]
i haven't done that, so I can't help there
13:26:54 [Swarup]
we're asking our DBAs to monitor on db side..
13:27:03 [Swarup]
ok
13:37:36 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
14:45:16 [Leftmost]
Leftmost has joined #musicbrainz-devel
15:02:23 [horieyui]
horieyui has joined #musicbrainz-devel
15:06:05 [hawke_1]
hawke_1 has joined #musicbrainz-devel
15:11:22 [rembo]
rembo has joined #musicbrainz-devel
15:37:31 [plaintext]
plaintext has joined #musicbrainz-devel
15:59:30 [Muz]
Muz has joined #musicbrainz-devel
16:00:29 [noobie]
noobie has joined #musicbrainz-devel
16:00:29 [noobie]
noobie has joined #musicbrainz-devel
16:06:23 [djce]
djce has joined #musicbrainz-devel
16:06:29 [ocharles]
bleh. how are track(tracklist, position) and medium(release, position) not unique!?
16:07:41 [reosarevok]
Because there was a ticket to make them unique but it was marked decision required?
16:07:43 [reosarevok]
(IIRC)
16:07:56 [ocharles]
sounds like something i'd complain about
16:07:57 [luks]
medium(release,position) should be
16:07:58 [ocharles]
* ocharles searches
16:08:03 [luks]
but for track you also need the medium
16:08:27 [ocharles]
luks: but a tracklist belongs to a single medium. a tracklist cannot have multiple tracks in the same position
16:08:46 [ocharles]
reosarevok: http://tickets.musicbrainz.org/browse/MBS-3537 you are correct
16:08:48 [luks]
hm, oh
16:08:58 [reosarevok]
ocharles: the tracklist thing I hadn't seen before though
16:09:19 [ocharles]
http://musicbrainz.org/tracklist/291674 is one offender
16:09:39 [ocharles]
interestingly marked as non-sequential
16:09:58 [ocharles]
oh wait, I guess that's the missing track 7
16:10:17 [reosarevok]
Guess so, yeah
16:10:22 [luks]
is that the internal position or the new track numbers?
16:10:56 [ocharles]
luks: internal position
16:48:46 [ruaok]
ruaok has joined #musicbrainz-devel
16:59:18 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
17:01:19 [voiceinsideyou1]
voiceinsideyou1 has joined #musicbrainz-devel
17:04:03 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
17:11:19 [reosarevok_]
reosarevok_ has joined #musicbrainz-devel
17:15:14 [reosarevok__]
reosarevok__ has joined #musicbrainz-devel
17:21:23 [reosarevok]
reosarevok has joined #musicbrainz-devel
17:23:29 [plaintext]
hi ruaok
17:24:27 [ruaok]
hi
17:24:31 [ruaok]
how are you today?
17:24:39 [reosarevok_]
reosarevok_ has joined #musicbrainz-devel
17:25:06 [plaintext]
ready to work :)
17:25:11 [plaintext]
sorry about yesterday
17:25:43 [ruaok]
no worries.
17:25:47 [ruaok]
where are you at?
17:25:55 [plaintext]
Malmö, Sweden
17:26:47 [ruaok]
lol. I meant in your project. :)
17:26:55 [plaintext]
oh lol
17:26:56 [ocharles]
haha
17:27:22 [reosarevok__]
reosarevok__ has joined #musicbrainz-devel
17:27:23 [plaintext]
well queries are read from a csv file, and then ran on the splunk server
17:27:28 [plaintext]
results are stored in the db
17:27:37 [plaintext]
the report_type column has no use yet
17:27:44 [plaintext]
and there's no metadata in the csv file yet
17:27:57 [plaintext]
and I still couldn't get codereview to accept my diffs :(
17:28:15 [ruaok]
I think it might be best for us to store the queries in another table or keep them in code.
17:28:30 [plaintext]
oh
17:28:31 [ruaok]
but a csv file isn't the best approach.
17:28:37 [plaintext]
you're right
17:28:50 [ruaok]
I would just make a new python module for just keeping queries.
17:28:55 [plaintext]
another table seems reasonable
17:28:56 [ocharles]
why not just save the queries in splunk?
17:29:12 [ocharles]
we are talking about splunk queries here ,right?
17:29:14 [ruaok]
ocharles: I feel that these queries should be under version control.
17:29:16 [plaintext]
yes
17:29:22 [ocharles]
ruaok: hm, true
17:29:33 [ocharles]
but kinda the point of splunk is to build up your queries there
17:29:52 [ocharles]
ie, why I saved http://splunk.musicbrainz.org/en-GB/app/search/%40go?s=Top%20%2Fws%2F2%2F%20queries
17:30:17 [ruaok]
hmm. and if splunk dies for some reason, our queries go away too.
17:30:25 [ruaok]
that makes backing up queries much more of a pain.
17:30:57 [ruaok]
lets go with a python module for now and revisit this later if we have to.
17:31:34 [ruaok]
then, since we can't get CR to work right, just post a message to mb-devel along with a link to where your sanitizing script is.
17:31:49 [plaintext]
okay
17:31:52 [ruaok]
ask people to review it outside of CR. have them leave comments on github.
17:31:59 [plaintext]
so what exactly should the python module do?
17:32:10 [ruaok]
just store the queries, thats it.
17:32:31 [plaintext]
oh ok
17:32:33 [ruaok]
POPULAR_ARTIST_QUERY = "<query>"
17:32:38 [plaintext]
I see
17:32:43 [ocharles]
yaml might be a better choice
17:32:44 [plaintext]
but in the future
17:32:48 [plaintext]
shouldn't it be in the db?
17:33:04 [plaintext]
because if people want to add a query they might not want to modify code
17:33:15 [plaintext]
of course a very limited number of people will add queries
17:33:24 [ocharles]
db has all the same drawbacks as storing it in splunk
17:33:33 [ruaok]
well, on the back-end there needs to be something that displays the results, right?
17:33:34 [ocharles]
except that you also have the drawback of convincing me that data belongs in our database ;)
17:33:47 [ruaok]
and that requires some code.
17:34:06 [ocharles]
I would have a yaml file containing all queries, and a python module to do dispatching
17:34:21 [plaintext]
hmm you convinced me
17:34:25 [ocharles]
python module does for query in load_queries('q.yaml'): splunk.run_query(query)
17:34:26 [ocharles]
or something like that
17:34:26 [ruaok]
http://pyyaml.org/
17:34:37 [reosarevok__]
Sorry about all that logging out and in, was fixing my router
17:34:38 [plaintext]
I have to read about yaml
17:34:45 [ruaok]
I leave the choice to you to use yaml or python. matters not.
17:34:46 [ocharles]
if it turns out that we do want a dynamic query store, we can come to that later
17:34:52 [ruaok]
I care that the code is under version control.
17:34:56 [ocharles]
* ocharles nods
17:35:30 [plaintext]
so I'll read about yaml and decide whether to use it
17:35:33 [ruaok]
plaintext: all the queries you have now run and deposit data in the database table?
17:35:50 [ocharles]
homeward bound
17:36:07 [ruaok]
ocharles: ping me when you get home. I want to chat about our servers for a bit.
17:36:07 [plaintext]
they do
17:36:11 [ruaok]
mothing major.
17:36:21 [plaintext]
I put " | head 1000" or something like that in each one
17:36:26 [plaintext]
so they run quick for testing purposes
17:36:29 [ruaok]
plaintext: ok, great.
17:36:33 [ruaok]
ok, fair nuff.
17:36:49 [ruaok]
you might want to make that an option anyway.
17:37:02 [ruaok]
so that it can be quickly turned on or off.
17:37:13 [ruaok]
do you have enough to do for the next hour?
17:37:17 [ruaok]
I want to head to the office.
17:37:21 [plaintext]
sure
17:37:23 [ruaok]
ok
17:37:24 [ruaok]
ttfn
17:42:24 [kepstin]
kepstin has joined #musicbrainz-devel
17:58:19 [djce]
djce has joined #musicbrainz-devel
18:29:38 [ruaok]
ruaok has joined #musicbrainz-devel
18:34:33 [ocharles]
ruaok: bing!
18:34:41 [ruaok]
bong!
18:34:43 [ruaok]
one sec.
18:35:51 [ruaok]
first off, where is your timesheet?
18:36:06 [ruaok]
too late now; you have another 1.8 days to get it done.
18:36:16 [ruaok]
bank holiday tomorrow; read ur mail.
18:36:40 [ruaok]
(its like the queen's jubilee, but without the queen)
18:37:27 [ocharles]
yea, i realised that on the way home
18:37:35 [ocharles]
there was "i swear I had something to do... ohh. get paid"
18:37:39 [ocharles]
>.<
18:37:59 [ocharles]
will be with you first thing uk morning
18:38:04 [Swarup]
Swarup has joined #musicbrainz-devel
18:38:14 [ruaok]
then, in london you said that our fcgi processes get killed after serving 2 requests.
18:38:21 [ocharles]
well, hand waving at 2 requests
18:38:27 [ocharles]
point is there's a quick turn over, yes
18:38:41 [ruaok]
well, the config in dbdefs states something very different.
18:38:56 [ocharles]
the config states max request or memory size
18:39:15 [ocharles]
if my memory serves me correctly
18:39:16 [ruaok]
is it or?
18:39:23 [ocharles]
yes
18:39:30 [ruaok]
if memory size OR minimum requests?
18:39:31 [ocharles]
it wouldn't make much sense to run out of memory but keep trying :)
18:39:33 [ocharles]
yes
18:39:44 [ocharles]
maximum requests*
18:39:56 [ruaok]
ah, the docs lead me to believe that it would do at least 30 requests before even checking the size.
18:39:56 [ocharles]
i'm double checking now though, haven't looked at this for a while
18:40:00 [Swarup]
hey Rob, ocharles..qq on db connections..do each fcgi process creates one dedicated db conn..
18:40:05 [ocharles]
oh, hm
18:40:39 [ruaok]
ocharles: can you answer Swarup's question?
18:40:47 [ocharles]
Swarup: yes
18:40:49 [ruaok]
I guess the answer is not necessarily, right?
18:40:55 [ocharles]
Swarup: if that's not optimal use pgpool
18:41:20 [ruaok]
ocharles: in production we have min_requests: 50
18:41:22 [ocharles]
ruaok: ok, i am wrong - it's request count > min requsets, then check memory stuff
18:41:24 [ruaok]
check every at 30
18:41:29 [ruaok]
yep.
18:41:39 [ocharles]
so the 60th request will be the first check
18:41:44 [ocharles]
i think
18:41:50 [ruaok]
still, quite frequent turnover regardless.
18:42:44 [ruaok]
http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?Mode=view;Template=1196205794.8081;Base=%2Fvar%2Fwww%2Fmrtg%2F%2Fastro_load.rrd
18:42:54 [ruaok]
I upped the amount of max ram to 400mb.
18:43:18 [ruaok]
and the dip you see on the past week right after week 1 was a result of that.
18:43:19 [Swarup]
where can i find more info on pgpool...is that something u guys are usiing prod?
18:43:48 [ocharles]
Swarup: we don't use it production yet, but may need to if we want to scale much further
18:43:54 [ruaok]
Swarup: we're not using it in production.
18:43:56 [ocharles]
we use it at last.fm
18:44:02 [ocharles]
Swarup: http://pgpool.net
18:44:08 [ruaok]
ocharles: http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?Mode=view;Template=1196204920.6439;Base=%2Fvar%2Fwww%2Fmrtg%2F%2Fastro_disk-physicalmemory.rrd
18:44:21 [ruaok]
that change didn't have much effect on total ram used.
18:44:26 [ruaok]
but it did on the load.
18:44:32 [ocharles]
interesting
18:44:33 [ruaok]
so, I think we can do a little more tuning.
18:44:43 [ruaok]
more clients. maybe go to 450mb.
18:44:56 [ocharles]
do we have a graph of average response time?
18:44:59 [ruaok]
there is bunches of ram we're not using right now, so we can tweak more.
18:45:05 [ruaok]
we od.
18:45:06 [ruaok]
do
18:45:28 [ruaok]
* ruaok looks
18:46:24 [ruaok]
http://stats.musicbrainz.org/webstats/nginx-rrd/drraw.cgi?Template=1324902714.24570&Base=%2Fusr%2Flocal%2Fwebstats%2Fnginx-rrd%2Frrd%2F%2Fnginx.lenny.musicbrainz-full.by_back_end.10_1_1_24_80.rrd&Mode=view
18:46:26 [ocharles]
the more memory thing is beneficial to non-ws users i think, because it means we can hold more templates in ram
18:46:34 [ocharles]
i don't think that should affect ws response times
18:46:35 [ruaok]
not sure if we have it in a way that is useful for our analysis
18:47:12 [ruaok]
maybe we should seriously think of having ws traffic go one 2 machines, web traffic to one.
18:47:39 [ocharles]
we could start less extreme and have web to 2, ws to 3
18:48:19 [ruaok]
and just see how that one odd machine out does?
18:48:21 [ianmcorvidae]
i.e. one ws-only machine?
18:48:24 [ocharles]
yea
18:48:33 [ianmcorvidae]
I think I'd prefer 2 and 2
18:48:33 [ocharles]
and make sure that the other 2 can handle the web load
18:48:38 [ianmcorvidae]
one web-only, one ws-only, one both
18:48:40 [ruaok]
I'd be more inclined to go the opposite way.
18:48:41 [ianmcorvidae]
test all the cases :)
18:48:54 [ruaok]
ianmcorvidae: +1
18:48:56 [ruaok]
I like that.
18:49:01 [ocharles]
test all cases at once though?
18:49:14 [ianmcorvidae]
sure, we're keeping one as before as the control
18:49:27 [ocharles]
one might not be enough to catch it if it doesn't work out
18:49:47 [ruaok]
well, and this is something we can change quickly if something goes wrong.
18:49:52 [ruaok]
djce: ping?
18:52:38 [ruaok]
ocharles: the upshot is the dbdefs.pm on astro has one modification to local code.
18:52:55 [ocharles]
hmm?
18:53:20 [ruaok]
I modified dbdefs.pm on astro just fyi
18:53:31 [ruaok]
its not checked in code, but just so you're aware.
18:53:36 [ocharles]
oh, ok
18:53:46 [ocharles]
gotcha
18:54:17 [ocharles]
astro has 16 cores?
18:54:45 [ruaok]
yea
18:55:35 [ocharles]
so it should in theory be able to operate at more than a 5 min load avg of 4
18:55:41 [ocharles]
?
18:55:57 [ruaok]
a load avg of 16 would be 100% loaded.
18:56:23 [ruaok]
so a 4 should be around 25% load
18:56:57 [ocharles]
yea
18:57:33 [ocharles]
we need more of an insight into how a typical worker behaves memory wise over its lifetime.
18:57:46 [ocharles]
if it's more or less constant memory now (little growth) we can have more workers
18:58:20 [ruaok]
well, the overall memory usage graph suggests that we have headroom.
18:58:23 [ocharles]
and maybe knowing request time over the lifetime of a worker too would be interesting
18:58:26 [ruaok]
and that we can easily add more workers.
18:58:45 [ocharles]
we also need to know the initially memory cost of a new worker, not sure how much memory a worker uses that isn't shared memory
18:58:50 [ruaok]
but I agree, getting more data on this would be good.
19:00:21 [ocharles]
i really want to get that load up though
19:00:29 [ocharles]
it feels like we're wasting a machine that's only at 25% load
19:00:36 [ocharles]
but i'm not a hosting guy :)
19:00:45 [nikki]
nikki has joined #musicbrainz-devel
19:00:49 [ruaok]
well, its all about headroom right?
19:00:52 [ruaok]
hi nikki.
19:00:59 [ruaok]
you have to leave room for traffic spikes.
19:01:03 [ocharles]
well sure we want some headroom, but 75%? :)
19:01:10 [ruaok]
but ideally you'd have each machine at 100%.
19:01:35 [ocharles]
we haven't gone past load of 4 in the past year really
19:01:43 [ruaok]
well, the answer to this is to automatically add and remove machines from the pool when you need more capacity.
19:01:43 [ocharles]
save a few blips which were caused by us, not traffic
19:01:48 [ocharles]
right
19:01:48 [ianmcorvidae]
* ianmcorvidae notes it's time for triage :)
19:01:57 [ruaok]
reosarevok: triage?
19:02:01 [ruaok]
warp: triage?
19:02:43 [ruaok]
and given that we dont have the ability to add/remove machines easily, this is the best we can do right now.
19:03:28 [ruaok]
plaintext: where is your code for running splunk queries?
19:03:39 [ruaok]
you should be committing to github on a regular basis.
19:03:51 [ruaok]
and your repo needs to organizing too. :)
19:04:53 [ruaok]
* ruaok prods reosarevok
19:04:57 [ruaok]
and warp!
19:05:04 [reosarevok]
* reosarevok is looking if http://scheduling.ocharles.org.uk/results is updated this time
19:05:15 [ocharles]
according to the load graphs on my server, it's been updating every hour
19:05:22 [reosarevok]
Yeah, seems good
19:05:22 [ruaok]
maybe I should send out a meeting request so people can put it their calendars.
19:05:27 [reosarevok]
* reosarevok is ready when warp is
19:05:33 [reosarevok]
(or in a min or two if he doesn't show up)
19:05:35 [ocharles]
https://stats4.linode.com/generate_graph.pl?linode=linode201327&username=ocharles&graph=cpu&span=daily look mah, i have rrd tools too!
19:05:45 [ocharles]
* ocharles somewhat expects that not to work for anyone else
19:05:47 [ruaok]
heh.
19:05:51 [ruaok]
session error is all I get.
19:05:53 [ianmcorvidae]
yup, session error :P
19:05:54 [ocharles]
:)
19:05:55 [ruaok]
nice graphs. :)
19:05:59 [ocharles]
well, good on linode :P
19:06:47 [ruaok]
these results have bugs that we've already triaged. :(
19:07:16 [Swarup]
hey ocharles..is there a db conn timeout setting..i suppose it just lives until the fcgi process dies..is that right?
19:07:27 [ocharles]
Swarup: yep, and reconnects if the connection drops
19:07:38 [ruaok]
ocharles: http://tickets.musicbrainz.org/browse/MBS-4954
19:07:41 [ocharles]
ruaok: bugs we've triaged but probably didn't reach a conclusion on
19:07:43 [ruaok]
is there anything left on that bug?
19:07:53 [ruaok]
ideally not having the redirect, but that is in another bug now.
19:07:54 [ocharles]
ruaok: did you see my last comment?
19:08:22 [ruaok]
I guess not. which comment?
19:08:46 [ocharles]
do i reallllly want to spoil the mystery for you? :{
19:08:48 [ocharles]
:)*
19:08:53 [ocharles]
"As we control both domains, that doesn't seem so pressing - this bug is at least fixed now. I have opened MBS-4960 to track the improved error handling work."
19:09:04 [ocharles]
so I think MBS-4954 is fine closed
19:09:15 [ruaok]
ah, yes. ok. just checking.
19:09:36 [ianmcorvidae]
we really need to wrap all our LWP calls in try/catch, presumably
19:09:39 [ocharles]
there is another ticket for not using the redirect too, iirc
19:09:50 [nikki]
yes
19:09:56 [ocharles]
ianmcorvidae: is it lwp that crashes?
19:10:09 [ocharles]
I thought lwp would just return a $response object that is !$response->is_success
19:10:20 [ocharles]
i haven't looked into the stack traces
19:10:39 [ruaok]
shall we start without warp?
19:11:07 [ocharles]
i'm ok with that
19:11:16 [ianmcorvidae]
lwp is crashing in several places
19:11:20 [ianmcorvidae]
some 'bad hostname' error
19:11:21 [ruaok]
ok, lets warp fail again.
19:11:37 [ruaok]
ianmcorvidae: what is the bad hostname? do we know?
19:11:46 [ocharles]
ianmcorvidae: ah, it can't make the connection at all. yes, I guess that is an exceptional condition
19:11:46 [ruaok]
reosarevok: start us off, please.
19:11:49 [ianmcorvidae]
blog.musicbrainz.org or metabrainz.org :)
19:11:53 [ocharles]
or test.metabrainz.org*
19:11:59 [reosarevok]
[MBS-2056] Merging Releases - Append Mediums (disc n) needs removal371
19:12:10 [ocharles]
12 seems fine
19:12:24 [ruaok]
ianmcorvidae: can you dump all the actual URLs that fail and get them into some tickets?
19:12:51 [ianmcorvidae]
it's not URLs failing, it's connections -- it's getting 'bad hostname' because DNS is screwing up
19:13:07 [ianmcorvidae]
it needs to be wrapped in try/catch so that when remote sites fail our site doesn't ISE :)
19:13:14 [ianmcorvidae]
and yeah, 12 looks good
19:13:17 [ocharles]
yep
19:13:26 [ruaok]
we should be using IP addresses for some of these cases anyway.
19:13:36 [ruaok]
why bother with a look up?
19:13:40 [ruaok]
12 is fine for me too
19:13:46 [reosarevok]
I guess 12 works, yeah. I wonder how much will be left to merge in 12 months that isn't almost impossible to prove+merge, but...
19:13:49 [ocharles]
because other people use our server
19:13:53 [ocharles]
if you meant internal ips
19:14:03 [ruaok]
yes, internal only.
19:14:14 [ocharles]
so that won't work for anyone outside our lan
19:14:15 [ruaok]
at least we should be using internal DNS.
19:14:35 [ruaok]
actually, that wont work inside either.
19:14:39 [ruaok]
vhosts. :(
19:14:50 [nikki]
* nikki notes that it's possible that the server itself might be down (which of course is still a problem, but she still thinks it shouldn't crash stuff on the mb site)
19:14:55 [ocharles]
* ocharles nods
19:14:58 [reosarevok]
* reosarevok waits for the weird conversation he doesn't understand to finish
19:15:05 [ruaok]
but, lets focus on triage for now.
19:15:24 [ruaok]
next reosarevok ?
19:15:26 [reosarevok]
[MBS-3781] No way to conveniently change all track artists and credits on a release263
19:15:45 [ruaok]
unsched in light of NES?
19:15:52 [nikki]
that's a ui thing...
19:15:52 [warp]
oh meh. late again.
19:15:52 [reosarevok]
How does NES change this?
19:15:53 [warp]
hello!
19:16:11 [ocharles]
reosarevok: it doesn't really change it
19:16:17 [ocharles]
nes is backend stuff, for the most part
19:16:21 [reosarevok]
So, no unsched in light of NES
19:16:22 [ocharles]
ui's wont really be affected
19:16:27 [ocharles]
i say 12 with this
19:16:34 [ocharles]
nes or not, this needs to be addressed soon
19:16:41 [reosarevok]
12 is OK, since there's a script that solves the issue
19:16:45 [nikki]
12
19:16:47 [ianmcorvidae]
12.
19:16:54 [reosarevok]
(problem being it's too ugly for the actual site)
19:17:11 [ruaok]
12 is fine then
19:17:32 [reosarevok]
[MBS-2919] Reports should have a way of marking that an item on the list has been checked, and should then be listed on the report362
19:17:43 [reosarevok]
I guess they mean *not* be listed
19:17:45 [ocharles]
this is doable in 12 now that db backed reports are almost done
19:17:59 [ocharles]
(I don't think they'll make this release, but it should hopefully be in the one after)
19:18:46 [ianmcorvidae]
12 is good for me
19:18:53 [nikki]
12 would be nice (although I had quite long argument with hrglgrmpf over how it should work :P)
19:18:58 [reosarevok]
12 works I guess
19:19:04 [ruaok]
fine
19:19:38 [reosarevok]
[MBS-3470] Setting HTTP caching headers (Etag, Expires) in Web Service responses171
19:19:49 [reosarevok]
No idea what it does, but it seems to be a 12 :p
19:19:57 [ianmcorvidae]
we already set etags, expires we can't, there's a different ticket for last-modified
19:20:00 [ianmcorvidae]
wontfix
19:20:05 [ianmcorvidae]
or invalid
19:20:06 [ianmcorvidae]
or duplicate
19:20:07 [ianmcorvidae]
something like that
19:20:10 [ocharles]
i say unsched
19:20:28 [ruaok]
unsched.
19:20:28 [ocharles]
hmm, expires can't be set so there's no work, you're right
19:20:33 [ocharles]
so close as fixed?
19:20:36 [ruaok]
sure
19:20:38 [plaintext]
ruaok: I'll push it in a minute
19:20:50 [plaintext]
and I'll organize the repo too
19:20:53 [ianmcorvidae]
other than slaves, which I guess is mentioned
19:21:01 [ocharles]
ianmcorvidae: if thee was an etag ticket or already, can you close as dupe to that ticket?
19:21:03 [ruaok]
plaintext: ok
19:21:09 [ianmcorvidae]
ocharles: sure, can do
19:21:19 [ocharles]
or just generally close it as you see fit
19:21:19 [ianmcorvidae]
I'll make a new ticket for "slaves should cache more heavily", since that's different anyway
19:21:36 [ocharles]
alright
19:21:45 [reosarevok]
[MBS-1153] Allow basic ARs to be auto-created during add/edit release process333
19:21:55 [reosarevok]
wontfix, bitmap's rel editor?
19:22:07 [reosarevok]
We definitely don't need to load the RE *more* right now
19:22:17 [reosarevok]
It's brittle enough as it is
19:22:20 [reosarevok]
Or maybe unsched?
19:22:37 [ruaok]
unsched and re-eval after bitmap is done.
19:22:39 [nikki]
it would be nice to be able to seed the re and have it go to the rel editor afterwards, but yeah, actually doing it in the re sounds like a nightmare
19:22:46 [ocharles]
i think ruaok's choice is good
19:23:07 [reosarevok]
Works for me
19:23:15 [warp]
this is about automatically creating certain ARs isn't it?
19:23:50 [reosarevok]
Oh
19:23:51 [reosarevok]
Wait
19:23:56 [reosarevok]
* reosarevok reads the actual ticket
19:24:04 [plaintext]
ruaok: https://github.com/metabrainz/musicbrainz-server-log-analysis/blob/master/run_queries.py
19:24:10 [reosarevok]
Wontfix
19:24:12 [plaintext]
I guess the whole "csv" thing has to disappear
19:24:32 [reosarevok]
Since we can't choose the right works, and we don't know if performer-as-artist really performs in all tracks
19:24:36 [warp]
I say wontfix. it's a confusing hack which makes some ARs slightly easier to add for those who know what they're doing.
19:24:52 [ocharles]
also fine with that
19:25:12 [ruaok]
plaintext: lets talk more about this after our triage meeting.
19:25:29 [reosarevok]
nikki? ianmcorvidae?
19:26:04 [ianmcorvidae]
I think unsched or wontfix is fine.
19:26:08 [nikki]
same
19:27:11 [ruaok]
unsched and onward!
19:27:17 [reosarevok]
[MBS-3485] batch add ARs to multiple works from an artists works page433
19:27:33 [reosarevok]
This is less urgent because of the userscript but still a good thing to have
19:27:39 [ocharles]
i don't think 3mo
19:27:50 [reosarevok]
Yeah, userscript = 12 mo I guess
19:27:59 [ruaok]
12 is fine
19:28:00 [ocharles]
i don't have time for another big project in the next 3 months, at least :)
19:28:25 [warp]
* warp ok with 12
19:28:37 [nikki]
* nikki wonders how bitmap's stuff will affect it
19:28:49 [reosarevok]
In no way I guess since it's not release-dependant
19:28:54 [plaintext]
ruaok: ok
19:28:58 [nikki]
surely most of the relationships people would want to batch add are things they also want to be able to do from the release page?
19:29:25 [reosarevok]
For non-classical, maybe
19:29:26 [ocharles]
yea, maybe we wait until after bitmap's work, and unsched it for now?
19:29:41 [reosarevok]
I mean, "also", yes, "only", no
19:29:52 [reosarevok]
But I guess that'd work
19:30:06 [ruaok]
+1 to ocharles
19:30:40 [reosarevok]
As long as we do check it after his work
19:30:46 [reosarevok]
How do we remind ourselves of that?
19:31:07 [ruaok]
do we have a ticket for bitmaps work that we can make this dependent on?
19:31:32 [ocharles]
reosarevok: we will have to go through unscheduled at some point in the future anyway
19:31:47 [ruaok]
unsched, onward!
19:31:49 [reosarevok]
Sure. In a year or two, at this rate :p
19:31:50 [reosarevok]
But ok
19:31:51 [reosarevok]
[MBS-3994] Adding data to a recording235
19:32:07 [reosarevok]
I can't imagine something more DECISION REQUIRED than this
19:32:15 [reosarevok]
(oh, already marked)
19:32:16 [reosarevok]
Unsched
19:32:25 [navap]
musicbrainz.org just had a few seconds of nothing but 502s
19:32:28 [ruaok]
and schema change. :)
19:32:29 [ocharles]
so vague
19:32:40 [reosarevok]
ocharles: the ticket itself is not vague
19:32:42 [ocharles]
though the description is a bit less vague
19:32:46 [ocharles]
not as*
19:33:00 [reosarevok]
Well, it seems pretty specific. Also huge, and not necessarily desirable
19:33:04 [reosarevok]
Anyway, unsched
19:33:09 [ruaok]
ocharles: that reminds me of one more hosting thing to talk about
19:33:18 [ruaok]
unsched and onward!
19:33:22 [ocharles]
yea, unsched, with a comment to split this up, consult style, etc
19:33:43 [warp]
* warp ok with unsched.
19:33:53 [reosarevok]
[MBS-3987] Disable recording duration editing224
19:33:56 [reosarevok]
came up already
19:34:05 [reosarevok]
ocharles: maybe we should hide decision required by default?
19:34:15 [reosarevok]
(or give them their own section)
19:34:20 [ocharles]
nah, i say we carry on with them as normal
19:34:27 [ocharles]
gotta get through them at some point
19:34:37 [ocharles]
if they have a lot of votes, we should be pushing to make that decision sooner
19:34:37 [reosarevok]
Point being, we end up going through them every week and losing time
19:34:48 [ocharles]
i didn't know we had to meet a quota :)
19:35:02 [reosarevok]
And 8 votes, 4 of which for unsched is not a lot :p
19:35:20 [reosarevok]
(maybe enough to unsched it though)
19:35:30 [ocharles]
we can't waste time talking about dec. req.ed tickets, but we can bike shed with meta topics?
19:35:31 [ocharles]
:)
19:35:40 [warp]
of course
19:35:51 [reosarevok]
Well, I want to take this ticket away since it's the second or third time we see it
19:35:55 [reosarevok]
So I'd gladly unsched it
19:35:56 [ocharles]
unsched
19:35:58 [ianmcorvidae]
unsched the ticket, move on
19:36:08 [warp]
(I agree we shouldn't see a ticket multiple times in these meetings)
19:36:18 [reosarevok]
[MBS-3610] Ratings : 502 Bad Gateway316
19:36:25 [reosarevok]
Didn't we decide about this thing already? :/
19:36:30 [ocharles]
do remember i messed up a few weeks ago
19:36:37 [ocharles]
could be from me :)
19:36:50 [reosarevok]
502, 12 mo
19:36:51 [ruaok]
2749 is the next one we havent talked about yet
19:36:55 [reosarevok]
(also, pagination, 12 mo)
19:37:04 [reosarevok]
(IIRC)
19:37:18 [warp]
502s are bad. 3 or 12.
19:37:22 [ocharles]
12
19:37:47 [reosarevok]
ruaok: we did talk about that one actually
19:37:55 [reosarevok]
* reosarevok skips those two
19:38:01 [ocharles]
we need to get to them
19:38:04 [ocharles]
lets just talk about them
19:38:09 [ocharles]
i have a document open with decisions
19:38:13 [ocharles]
poor mans write ahead log!
19:38:14 [ocharles]
:P
19:38:22 [reosarevok]
Fine
19:38:24 [reosarevok]
[MBS-1444] Make 'i' <-> 'ı' an auto-edit.334
19:38:28 [ocharles]
unsched
19:38:36 [reosarevok]
Poor Turks
19:38:42 [ruaok]
unsched. we talked about it.
19:38:48 [reosarevok]
But maybe they need a Turkish dev to fix it
19:39:00 [reosarevok]
Well, "takes time" is not a reason to unsched when people want it
19:39:05 [ocharles]
it needs someone to adopt a package on cpan
19:39:09 [reosarevok]
Oh, that was it
19:39:19 [ruaok]
maybe comp music will do it. :)
19:39:23 [reosarevok]
* reosarevok forgot what the time sink was
19:39:29 [reosarevok]
ruaok: suggest it to them? ;)
19:39:29 [hawke_1]
Turks, and people editing Spinal tap.
19:39:46 [ruaok]
reosarevok: you do it. in person. at the summit. :)
19:39:53 [warp]
o_O
19:40:07 [kepstin]
kepstin has joined #musicbrainz-devel
19:40:22 [ruaok]
next!
19:40:24 [reosarevok]
[MBS-2749] add checkboxes for merging works/recordings in search results.254
19:40:30 [ruaok]
ick.
19:40:32 [ruaok]
wontfix.
19:40:42 [warp]
why wontfix?
19:40:52 [ruaok]
we did that in classic.
19:40:54 [ocharles]
I know we were a bit blocked on this cause of lack of a sane ui
19:41:06 [ruaok]
and it cluttered up the results and then everyone wanted their pet feature in the search results.
19:41:12 [warp]
ruaok: ah
19:41:37 [ruaok]
anyone else?
19:41:45 [ocharles]
http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-06/2012-06-26.html#T19-12-44-496112
19:41:46 [reosarevok]
We didn't have thousands of unmerged works in classic though
19:41:54 [ocharles]
we agreed wontfix
19:41:55 [ocharles]
onwards!
19:42:16 [reosarevok]
[MBS-3339] Always show artist disambiguation column next to it when editing a release751
19:42:30 [ruaok]
3 seems fine
19:42:47 [reosarevok]
Can we turn this into "go back to the very nice classic system of stuff turning into a "locked" thing instead of the crap-search we have now"?
19:43:00 [reosarevok]
(that'd solve it easily :P)
19:43:11 [warp]
* warp ok with 3
19:43:13 [reosarevok]
I'm not sure how we'd solve this
19:43:19 [ocharles]
it's partially fixed
19:43:20 [reosarevok]
Just print the disambiguation everywhere?
19:43:27 [reosarevok]
The RE is messy already
19:43:30 [ocharles]
the edit's now show the correct artist with disambig stuff
19:43:34 [ocharles]
so maybe we call that "good enough"
19:43:41 [reosarevok]
This is *when editing*
19:43:42 [ocharles]
rather than introducing more ui inconsistency
19:43:43 [ruaok]
what is so crap about our current search?
19:43:46 [ocharles]
reosarevok: it's both, in the ticket
19:43:57 [reosarevok]
ruaok: not the search, but the fact it keeps being a search after selecting
19:44:00 [reosarevok]
(unlike in classic)
19:44:15 [ruaok]
keeps being a search??
19:44:19 [reosarevok]
In classic it turned into links instead, which was nicer and more readable
19:44:30 [ocharles]
we now show disambiguation stuff in the edit preview tab, and the submitted edit, that might be enough to close this
19:44:39 [ocharles]
it doesn't how much more we want to work on the release editor right now
19:44:48 [ocharles]
i suppose we could go for 12. I don't think it's urgent enough for 3
19:44:59 [reosarevok]
ruaok: When you select a release artist, the release artist field keeps being a search field, not a bold, fixed artist with a small edit button as in classic
19:45:02 [reosarevok]
That's what I'm saying
19:45:13 [nikki]
* nikki still misses the behaviour reosarevok is talking about
19:45:30 [warp]
nikki, reosarevok: is there a ticket for getting that behaviour back? :)
19:45:38 [nikki]
hmm
19:45:59 [nikki]
possibly. I don't remember if I entered a ticket or only thought about doing so
19:46:39 [reosarevok]
Please make sure and do it if not
19:46:44 [reosarevok]
Anyway, this ticket
19:46:46 [reosarevok]
12 I guess
19:46:52 [reosarevok]
Although I still can't see a good way of displaying it
19:46:58 [ruaok]
12
19:47:00 [warp]
I agree with ocharles that showing it in the edit and edit preview is sufficient for fixing this ticket. close as fixed.
19:47:01 [reosarevok]
(apart from the tooltips we have now)
19:47:11 [ocharles]
warp: ok, cool
19:47:52 [reosarevok]
[MBS-3796] Release editor can allow the same artist to be created twice without either having a disambig comment333
19:48:02 [ocharles]
3
19:48:07 [ruaok]
3 thats a bug.
19:48:09 [reosarevok]
Really?
19:48:18 [ocharles]
yes, this is going against our data integrity
19:48:24 [ruaok]
* ruaok nods
19:48:28 [reosarevok]
It involves adding two identic artists in two release editors open at the same time
19:48:30 [ocharles]
we should really have a unique constraint on artist name where comment is null
19:48:38 [reosarevok]
It's the kind of stuff only the ticket reporter would try :p
19:48:48 [reosarevok]
(or nikki to break stuff maybe)
19:48:59 [reosarevok]
But well, if there's a deeper problem then I'm fine with 3
19:49:07 [warp]
I'd say 12, but ok with 3.
19:49:14 [ocharles]
hmm
19:49:15 [warp]
(seems a pretty rare situation to end up in)
19:49:19 [ocharles]
i misunderstood it
19:49:24 [ocharles]
i thought it was the same artist in one release editor
19:49:29 [ocharles]
so yea, i'll drop my vote to 12
19:49:37 [reosarevok]
I mean, if the problems are "the constraints are wrong", that might still be a 3, I don't know
19:49:44 [reosarevok]
But 12 sounds good enough to me
19:49:48 [kepstin]
the error handling user interface would be weird in this. You could always just make it ise if someone does that ;)
19:50:22 [reosarevok]
12 then?
19:50:25 [ocharles]
yea
19:50:26 [ruaok]
12 and onward.
19:50:36 [reosarevok]
[MBS-3995] Username with an exclamation mark returns HTTP 400521
19:50:39 [kepstin]
but you'd have to do the check when you hit submit on the final release editor page, then send you back if constraints are invalidated
19:50:53 [reosarevok]
The text of the ticket says "ws/1"
19:50:58 [reosarevok]
Is this true for ws/2?
19:51:01 [reosarevok]
If not, do we care?
19:51:09 [ruaok]
we should
19:51:23 [warp]
reosarevok: I expect it is true for /ws/2 as well.
19:51:25 [warp]
3
19:51:33 [reosarevok]
If it's true for /2, then 3
19:51:39 [reosarevok]
At least see if it is in 3
19:52:13 [reosarevok]
ocharles? nikki? ianmcorvidae?
19:52:17 [ocharles]
3 is fine
19:52:23 [ruaok]
yep, 3
19:52:26 [ruaok]
onward.
19:52:38 [reosarevok]
[MBS-2848] New "Add medium" artist credits section is cluttered and hard to parse432
19:52:58 [reosarevok]
* reosarevok still finds it kinda OK but still would agree with nikki's proposed fix
19:53:30 [reosarevok]
(and 12)
19:54:21 [ocharles]
12 is ok
19:54:23 [ruaok]
* ruaok has no feelings
19:54:32 [reosarevok]
We all knew that, ruaok
19:54:36 [reosarevok]
What about the ticket?
19:54:38 [reosarevok]
:)
19:54:39 [warp]
oh, in the edit view
19:54:55 [ruaok]
* ruaok looks for plane tickets to ee to slap reosarevok silly
19:55:04 [reosarevok]
:)
19:55:13 [warp]
12 based on votes.
19:55:16 [reosarevok]
Yeah, in the edit view
19:55:17 [reosarevok]
Ok
19:55:21 [reosarevok]
12 then
19:55:28 [ianmcorvidae]
12 is good
19:55:30 [reosarevok]
[MBS-3492] When search rate limiter is hit, /ws/1 returns 200 with no body033
19:55:37 [reosarevok]
* reosarevok looks at the ceiling
19:55:41 [reosarevok]
People who use the ws, discuss
19:55:59 [ianmcorvidae]
should return 503, I presume, since it's a rate-limit issue
19:56:03 [reosarevok]
Seems to affect BBC in annoying ways so I guess we should fix it?
19:56:03 [ruaok]
yeah.
19:56:06 [ruaok]
bug, ergo 3
19:56:09 [ocharles]
fine with 3
19:56:13 [warp]
ok with 3
19:56:19 [ianmcorvidae]
I'd have said 12 but 3 works for me
19:56:23 [ocharles]
is this even the right project?
19:56:41 [ocharles]
ah, mb-server is handling it wrong
19:56:43 [ianmcorvidae]
I think it's in our code, failing to generate a 503 when it should be
19:56:44 [ocharles]
nvm, 3 is fine
19:56:44 [ianmcorvidae]
yeah
19:56:59 [reosarevok]
[MBS-1376] Try to avoid non-Latin sortnames057
19:57:12 [reosarevok]
Let's unsched this, since it's still mine and I'm still half-unconvinced :p
19:57:19 [ocharles]
heh
19:57:20 [ocharles]
ok
19:57:26 [ocharles]
that's inline with the votes
19:57:35 [reosarevok]
[MBS-3098] keep merge info in closed edits435
19:57:35 [ruaok]
k
19:57:39 [reosarevok]
That sounds pretty useful
19:57:49 [reosarevok]
But is it doable pre-NES at all?
19:57:49 [nikki]
yes
19:57:50 [ocharles]
nes
19:57:52 [ocharles]
no
19:57:52 [warp]
NES
19:58:09 [ocharles]
well doable, but i'm not going to do it
19:58:12 [ruaok]
NES and onward.
19:58:43 [reosarevok]
[MBS-3184] Create a /cdi/enter.html page (Like Mason/Classic) that asks people to update Picard plugin144
19:58:52 [reosarevok]
This again
19:59:01 [ruaok]
didnt we unsched that?
19:59:13 [warp]
I expected we decided something
19:59:20 [nikki]
wasn't the result close and reopen to add a redirect if anyone actually encounters the problem?
19:59:31 [reosarevok]
Dunno but it sounds sensible
19:59:33 [reosarevok]
Let's do that
19:59:47 [ruaok]
k
19:59:47 [nikki]
so if it's stopped being a problem, we do nothing, if it is still a problem, we add a redirect to a doc page :P
19:59:48 [ianmcorvidae]
sounds good
19:59:49 [ocharles]
ok
19:59:53 [warp]
I'm ok with that.
20:00:03 [reosarevok]
[MBS-3922] Filter edits by collections154
20:00:12 [reosarevok]
a.k.a. "poor man's subscribe to release"
20:00:22 [reosarevok]
Is this part of alastairp's work?
20:00:28 [ocharles]
i don't think so
20:00:43 [ocharles]
edit search will be massively changed by nes, so i don't see it worth spending time on it
20:00:57 [ruaok]
+1 then.
20:00:59 [warp]
* warp nods.
20:01:01 [ocharles]
so just unsched
20:01:06 [ruaok]
unsched and make a dependency of the NES ticket
20:01:09 [ocharles]
it might still be useful to be able to search merge requsets in side your collection
20:01:11 [ocharles]
+1
20:01:19 [ruaok]
onward
20:01:21 [reosarevok]
That means no changes at all will be made to edit search until NES? :/
20:01:28 [reosarevok]
(because it's still missing plenty of stuff)
20:01:31 [ocharles]
reosarevok: unless you find someone else to hire
20:01:34 [nikki]
and it's still got bugs
20:02:19 [ruaok]
nikki: how critical are those bugs?
20:02:32 [reosarevok]
I mean, this one might be big enough to actually postpone
20:02:49 [reosarevok]
But "no changes to edit search" is not the way to go for people who actually use the edit search
20:02:56 [nikki]
I dunno. I imagine they'll come up in scheduling at some point :P
20:03:05 [reosarevok]
Which are the ones we have it for, after all
20:03:13 [ruaok]
if there are bugs that are preventing you from doing stuff, then we should talk about them.
20:03:15 [nikki]
there's one where the search by relationship type thing is incomplete, half the relationships are missing for some bizarre reason
20:03:20 [ruaok]
but improvements should wait til post NED
20:03:23 [ruaok]
NES even.
20:03:28 [nikki]
that one annoys me 'cause I have to edit hte url myself to do the search I want :/
20:03:52 [reosarevok]
That sounds reasonably more sensible, as long as "should clearly work but doesn't" (like nikki's one) is a bug and not an improvement
20:03:54 [ocharles]
ruaok: that sounds ok
20:04:11 [ruaok]
nikki: which bug is that one? lets look at it before we close.
20:04:18 [reosarevok]
Anyway, ok with this one
20:04:29 [ruaok]
onward then.
20:04:36 [reosarevok]
[MBS-3957] When changing a track duration, if difference is > 15 seconds, recording association should be confirmed or changed741 has an insane amount of votes for it, but is it doable in any non-hideous way?
20:04:41 [nikki]
ruaok: http://tickets.musicbrainz.org/browse/MBS-4313
20:05:29 [ocharles]
hmm
20:05:41 [ocharles]
reosarevok: well, we could add a checkbox at the bottom of the recording assoc page perhaps
20:05:44 [ocharles]
a single checkbox
20:06:00 [ruaok]
I agree that we should do it. not sure that we need to find the UX fix now.
20:06:10 [warp]
re
20:06:20 [reosarevok]
I guess it can be just done by unsetting the recording
20:06:22 [ruaok]
3 and then discuss in meeting?
20:06:30 [nikki]
we already have stuff on the recordings tab for confirming recording associations
20:06:34 [reosarevok]
although that doesn't avoid people just pressing "yes, sure" again
20:06:40 [reosarevok]
Unless we explain why
20:07:21 [reosarevok]
I'm OK with that
20:07:28 [reosarevok]
We can do 3 for unsetting at least
20:07:31 [warp]
reosarevok: we already have interface stuff to ask for confirmation
20:07:43 [reosarevok]
warp: but we don't say *why* it was unset
20:07:46 [warp]
doesn't this ticket just ask for the assoc algoritm to be tweaked?
20:07:59 [reosarevok]
So they might be like "another annoying unset when it's clearly no change, click, click, onwards"
20:09:12 [reosarevok]
But yeah, the first step is that tweak and that's fine for 3
20:09:15 [reosarevok]
(IMO)
20:09:52 [warp]
* warp ok with 3
20:10:22 [reosarevok]
ocharles?
20:10:27 [reosarevok]
(let's do nikki's one and stop)
20:10:34 [ruaok]
yes.
20:10:42 [ocharles]
fine with 3, it'll probably be warps ticket :)
20:10:44 [reosarevok]
Ok
20:10:45 [reosarevok]
[MBS-4313] "has cover art" missing from Relationship Type multiple select box on "Search for Edits" page.431
20:11:04 [reosarevok]
(not sure if that's the only one missing, so I guess it'd be "some reltypes missing" etc
20:11:04 [reosarevok]
)
20:11:06 [ianmcorvidae]
bug, 3
20:11:14 [reosarevok]
Fine with 3
20:11:15 [nikki]
* nikki is biased and abstains :P
20:11:23 [ianmcorvidae]
I mean, I guess I'm also biased, but still :P
20:11:26 [ruaok]
3
20:11:30 [ocharles]
fine
20:11:54 [ruaok]
right-o.
20:11:57 [ruaok]
thanks everyone.
20:11:59 [reosarevok]
Thanks all, etc
20:12:02 [the_metalgamer]
the_metalgamer has joined #musicbrainz-devel
20:12:15 [ruaok]
ocharles: for when we do a release...
20:12:16 [reosarevok]
Go have food, beer or whatever you have at (late/early)
20:12:18 [ianmcorvidae]
hey ocharles, is http://tickets.musicbrainz.org/browse/MBS-4514 actually in the release? I'm thinking it isn't -- and if it is it should get assigned :)
20:12:21 [reosarevok]
:)
20:12:24 [ruaok]
we should also restart nginx .
20:12:26 [ocharles]
* ocharles gives up on having dinner tonight
20:12:32 [ianmcorvidae]
heh
20:12:38 [ocharles]
ruaok: restart?
20:12:44 [ocharles]
reload yes, but a full restart?
20:13:05 [ruaok]
the weird crash on sunday was the nginx handling all the requets as normal, but returning 502 for some reason.
20:13:08 [ruaok]
it was really odd.
20:13:19 [ocharles]
ianmcorvidae: 4376 resolves it
20:13:24 [ocharles]
but that's not in the release so...
20:13:28 [ruaok]
the whole site was working as normal, but nginx would return 502, even though the log said 200.
20:13:28 [ocharles]
no, it shouldn't be there
20:13:33 [ocharles]
that's really funky
20:13:35 [ianmcorvidae]
okay
20:13:38 [ianmcorvidae]
I'll pull it out, anyway :)
20:13:41 [ocharles]
ta
20:13:43 [nikki]
nikki has left #musicbrainz-devel
20:13:51 [ruaok]
a reastart of both servers on all three servers fixed the problem.
20:14:00 [ruaok]
I wonder how often nginx needs restarting.
20:14:02 [ocharles]
when did you do the restart?
20:14:15 [ruaok]
just before the problem went away. :)
20:14:18 [ocharles]
yes, but when
20:14:19 [ocharles]
today?
20:14:20 [ocharles]
yesterday?
20:14:25 [ocharles]
we had 502s 30 minutes ago
20:14:27 [ruaok]
sunday.
20:14:38 [ruaok]
these were not the usual transient 502s.
20:14:42 [ocharles]
hm
20:14:44 [ruaok]
this was persistent downtime for 5 minutes.
20:15:14 [ocharles]
well if you want an nginx restart, that's just another line in the fabric deployment script
20:15:22 [ruaok]
yes, please.
20:15:23 [ocharles]
give me a ticket and i'll do it
20:15:25 [ruaok]
full restart.
20:15:26 [ruaok]
ok
20:15:29 [ocharles]
assign to me
20:15:38 [ruaok]
k
20:15:45 [ruaok]
do we have a fabric component or project?
20:15:49 [ruaok]
or just MBS?
20:15:52 [ocharles]
it's an mbs issue, yea
20:16:04 [ocharles]
don't worry about components and stuff, i only filter on asignee
20:16:17 [warp]
ruaok: the fabric script lives in the musicbrainz repository.
20:16:22 [ruaok]
k
20:17:03 [ianmcorvidae]
MBS/Admin, I guess :)
20:17:09 [ruaok]
http://tickets.musicbrainz.org/browse/MBS-4963
20:17:15 [ruaok]
MBS/scripts.
20:17:24 [ianmcorvidae]
that works
20:18:05 [warp]
I'm off.
20:18:09 [warp]
goodnight sirs, madam!
20:18:54 [ruaok]
nn
20:23:53 [plaintext]
so is the meeting over?
20:24:44 [ianmcorvidae]
plaintext: yeah, it is
20:25:08 [Freso]
* Freso is reading backlog - would anyone clarify to me (when I got to here) what "12" is?
20:25:24 [ianmcorvidae]
Freso: we were doing triage, assigning tickets to 3 months, 12 months, or unscheduled
20:25:28 [ocharles]
Freso: we will try our hardest to fix it within 12 months from today
20:25:33 [ianmcorvidae]
(i.e. within 3 months, within 12 months)
20:30:21 [ruaok]
plaintext: sorry, I had to handle several requests.
20:31:09 [ruaok]
on run_queries.py, you should add a config file section.
20:31:30 [ruaok]
your PG_CONN_STR stuff has settings that work only for you right now.
20:33:08 [plaintext]
okay
20:33:41 [plaintext]
but by "for you" do you mean from rika from my user?
20:33:43 [ruaok]
so, the way to handle that is to create a separate config file. there are several options in python how to do that.
20:33:45 [ruaok]
pick one.
20:33:56 [ruaok]
yes, your rika config.
20:34:03 [plaintext]
I see
20:34:13 [ruaok]
so, you'll have something like:
20:34:32 [ruaok]
config.py.default or config.xml.default.
20:34:42 [ruaok]
and it has default config bits that are checked in.
20:34:53 [ruaok]
bu the config.py (or confix.xml) will never be checked in.
20:34:57 [plaintext]
and the config should contain stuff like port, user, host, etc?
20:35:03 [ruaok]
so that your local config bits never actually make it to git.
20:35:05 [ruaok]
yes.
20:35:21 [plaintext]
I see
20:35:25 [ruaok]
and then use those config bits in every script that needs it.
20:35:37 [plaintext]
okay
20:35:45 [ruaok]
and you should create more structure in your repo.
20:35:54 [plaintext]
yeah, sorry about that
20:36:01 [ruaok]
one dir for sanitizing stuff.
20:36:07 [ruaok]
another one for querying
20:36:12 [ruaok]
and another one for reporting.
20:36:20 [ruaok]
perhaps one for common stuff to all three.
20:36:34 [ruaok]
I'm going to run out and get some lunch.
20:36:54 [plaintext]
okay
20:36:55 [ruaok]
after that, I will review and re-run the sanitizer script and see if we can get autmatic log importing working.
20:37:00 [ruaok]
back soon.
20:37:30 [plaintext]
I think I'll be busy for a while with other stuff if that's okay
20:37:36 [plaintext]
I'll be ready to work in 2 hours
20:46:21 [Freso]
ianmcorvidae, ocharles: Arigato :)
20:46:41 [ocharles]
ianmcorvidae: did you look at caching stuff at all?
20:46:50 [ianmcorvidae]
ocharles: no, I haven't
20:46:57 [ocharles]
k
20:48:50 [ocharles]
Swarup: it's just dawned on me i meant pgbouncer, not pgpool
20:48:52 [ocharles]
sorry
21:11:13 [ruaok]
plaintext: ping.
21:11:30 [ruaok]
tomorrow is a bank holiday here and I am going to try and enjoy myself for a bit.
21:11:42 [ruaok]
so we need to get you all set to work through tomorrow.
21:12:15 [plaintext]
ruaok: pong
21:12:18 [plaintext]
okay
21:12:38 [ruaok]
I'm also looking at the other things I have to do. piles and piles of stuff. :(
21:12:48 [plaintext]
oh
21:12:53 [ruaok]
the installation of log sanitizer may not happen until thu.
21:13:00 [ruaok]
does that screw up your plans?
21:13:33 [plaintext]
Well I'm not sure what the plan is for this week
21:13:53 [plaintext]
it was something like "get things periodically running"
21:13:58 [ruaok]
write code and kick ass? :)
21:14:05 [plaintext]
yeah
21:14:52 [ruaok]
after you've done the things we talked about, you can start working on how to present this data on the musicbrainz-server pages.
21:14:58 [plaintext]
okay
21:16:10 [ruaok]
I think doing that right is going to take the rest of the time.
21:16:14 [ruaok]
oh. and....
21:16:26 [ruaok]
the machine what runs webalizer for us is overloaded.
21:16:33 [ruaok]
webalizer is really ancient anyway. :(
21:16:50 [ruaok]
http://stats.musicbrainz.org/webstats/zaphod/musicbrainz-full/
21:17:10 [ruaok]
we may want to replace webalizer with your stuff.
21:17:35 [ruaok]
remind me, do you know perl?
21:18:07 [plaintext]
yeah, I'm not an expert, but I know some :)
21:18:16 [ruaok]
ok. thats fine.
21:18:24 [ruaok]
should be doable for the display stuff.
21:18:29 [ruaok]
which isn't going to be rocket science.
21:18:39 [plaintext]
great
21:18:52 [plaintext]
so how do we replace webalizer?
21:19:00 [ruaok]
more queries.
21:19:02 [ruaok]
thats it. :)
21:19:12 [plaintext]
I see
21:19:22 [ruaok]
the link I just sent you -- we dont need to have everything replaced.
21:19:36 [ruaok]
Monthly Statistics for June 2012
21:19:56 [ruaok]
Top 30 of 10004426 Total URLs
21:20:04 [ruaok]
Top 10 of 10004426 Total URLs By kB F
21:20:17 [ruaok]
Top 30 of 4004229 Total Sites
21:20:24 [ruaok]
Top 10 of 4004229 Total Sites By kB F
21:20:31 [ruaok]
Top 30 of 1110867 Total Referrers
21:20:38 [ruaok]
it would be nice if we can do those.
21:20:41 [plaintext]
I can't see the Top 30/10 parts
21:20:47 [plaintext]
oh I see so we should do that
21:20:53 [plaintext]
yeah that would be nice
21:21:09 [ruaok]
then we can skip doing webalizer for the main site.
21:21:18 [plaintext]
and then display it like webalizer is displayed?
21:21:23 [ruaok]
but, this is not very important it.
21:21:26 [ruaok]
yes.
21:21:31 [ijabz]
ijabz has joined #musicbrainz-devel
21:21:37 [ruaok]
something to keep in mind, something to do if you have time.
21:21:50 [ruaok]
but getting the basic reporting and display happening is the next thing to do.
21:21:51 [plaintext]
okay
21:22:16 [ruaok]
but we're just now coming up on the half way point and I feel we're about half way.
21:22:31 [ruaok]
we knew that this project wasn't going to be cut and dry. lots of exploration.
21:22:35 [plaintext]
nice to hear that
21:22:37 [ruaok]
so where we're at, makes me happy.
21:22:52 [ruaok]
but, we both know the display/reporting is going to be a lot of work.
21:22:56 [ruaok]
so, keep at it!
21:23:03 [plaintext]
okay! :)
21:23:18 [ruaok]
I'll be around for another 90 minutes.
21:23:19 [bitmap]
bitmap has joined #musicbrainz-devel
21:23:27 [ruaok]
hit me with any questions.
21:23:33 [ruaok]
otherwise I'll talk to you on thursday.
21:24:00 [plaintext]
okay
21:24:08 [plaintext]
I think I'm set
21:25:00 [ruaok]
swet.
21:25:13 [ruaok]
lets set our goal for the end of next week to be displaying one report page.
21:25:18 [ruaok]
like the top artists page.
21:25:24 [ruaok]
is that an acceptable goal?
21:25:28 [plaintext]
yeah
21:25:38 [ruaok]
and I'll get the loading of the logs happening this week
21:25:39 [ruaok]
k
21:25:59 [plaintext]
so are you thinking about a whole page for one report?
21:26:12 [plaintext]
where would the link be to these pages?
21:26:43 [ruaok]
I haven't thought about reports per page, but I suspect that in most cases we want more than one report per page.
21:26:51 [ruaok]
depends. we need to look at it as it evolves.
21:27:12 [ruaok]
http://musicbrainz.org/statistics
21:27:18 [ruaok]
I think we should create more tabs there.
21:27:28 [ruaok]
or possibly a whole new page.
21:28:15 [plaintext]
yeah. I was just confused because you said "report page"
21:28:20 [plaintext]
tabs make sense
21:28:28 [ruaok]
* ruaok is handwaving
21:30:30 [ianmcorvidae]
if it's a report per tab and more than 1-2 reports, I'd say put them on a new base page
21:30:45 [ruaok]
ianmcorvidae: I think you're right about that.
21:30:49 [ianmcorvidae]
there's already a bunch of tabs on that, and this is a somewhat different thing, so separating them makes sense to me :)
21:31:12 [plaintext]
okay
21:31:19 [ruaok]
yeah, I'm not going to stress about that until we can get an idea as to what data we have to work with.
21:33:11 [ruaok]
oh and you should be committing your musicbrainz-server changes someplace.
21:34:24 [plaintext]
what repository?
21:35:09 [ruaok]
good question.
21:35:22 [ruaok]
ianmcorvidae: do you know if we gave bitmap commit rights to the main repo?
21:35:31 [ruaok]
or alastairp for that matter.
21:35:49 [bitmap]
I can create branches, or I was able to before at least
21:36:26 [MBChatLogger]
http://git.musicbrainz.org
21:36:26 [ianmcorvidae]
I feel like not to master, but to git.mb.org anyone can have access for their own branches AFAIK
21:36:48 [ianmcorvidae]
github is more complex, but there may as well just make a fork anyway
21:37:43 [ianmcorvidae]
I feel like the straightforward way to do it is to make a github fork, anyway
21:38:01 [ruaok]
ianmcorvidae: that is my feeling too.
21:38:15 [ruaok]
plaintext: just fork this: https://github.com/metabrainz/musicbrainz-server
21:38:29 [ruaok]
and then commit to a branch and push that branch to github on a regular basis.
21:38:42 [ruaok]
I want to follow you work on that project too
22:07:30 [kurtjx_]
kurtjx_ has joined #musicbrainz-devel
22:15:55 [plaintext]
okayá
22:21:55 [Freso]
Freso has joined #musicbrainz-devel
22:46:06 [the_metalgamer]
the_metalgamer has joined #musicbrainz-devel
23:24:21 [kurtjx]
kurtjx has joined #musicbrainz-devel
23:29:21 [plaintext]
plaintext has joined #musicbrainz-devel