The Wayback Machine - http://web.archive.org/web/20150915101834/http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-01/2012-01-05.html

IRC log of musicbrainz-devel on 2012-01-05

Timestamps are in UTC.

00:11:15 [bbliss]
OK, got my database working, but queries are VERY slow (60s+, esp. /ws/1/release/lookup) -- comparing what i've got to the prebuilt image, it looks like I have debug on somehow, which must be what's slowing it down.
00:11:19 [bbliss]
how do I disable debug?
00:11:50 [ruaok]
the debug doesn't slow it down.
00:11:59 [ruaok]
you probably need to give postgres more ram.
00:12:17 [bbliss]
hmm, OK. it's a 1GB rackspace instance with nothing else running on it
00:12:23 [bbliss]
ram usage is maxed in top tho
00:12:34 [bbliss]
but not swapping
00:12:39 [ruaok]
1G is not enough ram to get any kind of performance.
00:12:52 [ruaok]
our DB server which does nothing but run the DB has 24GB
00:12:53 [bbliss]
ok, is 2 enough or should i bump it to 4 right away?
00:12:59 [bbliss]
* bbliss drools.
00:13:02 [ruaok]
and it eats it all.
00:13:12 [ruaok]
4 is minimum.
00:13:20 [ruaok]
give 1 to postgres. at least.
00:14:14 [bbliss]
OK, i'll bump it up to 4. thanks!
00:14:44 [reosarevok]
Why not up to 11? :p
00:15:37 [bbliss]
heh.
00:19:28 [Leftmost]
Leftmost has joined #musicbrainz-devel
00:19:28 [Leftmost]
Leftmost has joined #musicbrainz-devel
00:51:29 [sezuan]
sezuan has joined #musicbrainz-devel
01:11:58 [bbliss]
well, that brought me from 60s a query down to 20s per query... 20s is still really slow though.
01:12:41 [bbliss]
it seems like the VM i have that's running the .ovf image isn't using anywhere near 4GB of ram though, and it's very quick (<1s responses usually)
01:44:25 [Leftmost]
Leftmost has joined #musicbrainz-devel
02:00:07 [ruaok]
ruaok has joined #musicbrainz-devel
02:15:49 [nikki]
nikki has joined #musicbrainz-devel
04:42:34 [nikki]
has the data been reloaded on test?
05:58:17 [ianmcorvidae]
nikki: an hour late but yes, it should have been -- warp was testing some things using it and wanted the data refreshed
05:59:32 [nikki]
oh :/
06:00:51 [nikki]
* nikki annoys ruaok and asks if he can make her an auto-editor again on test
06:03:56 [ianmcorvidae]
hehe
06:05:31 [kepstin-laptop]
kepstin-laptop has joined #musicbrainz-devel
06:32:37 [nikki]
does anyone know anything about https://www.transifex.net/projects/p/musicbrainz-server/ ? it's not ours 'cause we already have one at https://www.transifex.net/projects/p/musicbrainz/
06:33:04 [nikki]
and I don't recognise the username either
06:39:24 [ruaok]
musicbrainz_db_20111102=> update editor set privs = 255 where name = 'nikki';
06:39:24 [ruaok]
UPDATE 1
06:39:31 [nikki]
\o/
06:39:32 [nikki]
thanks!
06:42:38 [nikki]
stupid transifex
06:43:00 [nikki]
I installed their client to get the damn data out of there and it just gives me an error that doesn't show up in google
08:19:39 [kepstin-laptop]
kepstin-laptop has joined #musicbrainz-devel
09:10:29 [ijabz]
ijabz has joined #musicbrainz-devel
09:24:32 [ijabz]
ijabz has joined #musicbrainz-devel
09:49:47 [ocharles]
* ocharles gets to work on zero-downtime updates for beta
10:01:12 [djce]
djce has joined #musicbrainz-devel
10:15:10 [ocharles]
hurrah, no more downtime for beta
10:15:47 [ocharles]
djce: ping
10:15:52 [djce]
pong
10:16:29 [ocharles]
djce: ah good you're around. so I've been working on this zerodown time update for beta, and it works by using a socket file instead of a tcp socket to run the fastcgi proc manager on
10:16:38 [ocharles]
it brings up a new set of processes attached to the same socket
10:16:46 [ocharles]
and if that's successful, it takes the old one down
10:16:55 [ocharles]
I'm not sure how to integrate this into daemontools though
10:17:11 [ocharles]
https://gist.github.com/83a4d133b7d279b7a264 is said script
10:17:11 [djce]
do you mean it creates a /new/ socket, then renames it into place?
10:17:48 [ocharles]
nope, it just uses the same filename
10:18:00 [djce]
surprised that's possible
10:18:04 [ocharles]
heh
10:18:13 [ocharles]
well it seems to work :)
10:18:19 [djce]
so does that mean that for some period, requests are served by old+new at random?
10:18:28 [ocharles]
yea
10:18:38 [djce]
Is that what you want?
10:18:59 [ocharles]
it's not much of a problem, because the old proc manager gets told to shut down the moment the new one comes up, so the window is pretty small
10:19:12 [ocharles]
i don't think it'll be a problem
10:19:48 [djce]
The alternative would be to have the new service start, warm up (on a separate socket),
10:19:55 [djce]
and once it's warmed up (hand waving),
10:20:12 [djce]
rename its socket into place and shut down the old service
10:20:28 [djce]
then next time around of course, the same in reverse.
10:21:04 [djce]
* djce ponders to see if that's stable
10:21:36 [ocharles]
also a fine approach, but not sure if my shell script fu is up to that
10:21:59 [djce]
hmm. lemme have a think about that/
10:22:00 [djce]
.
11:29:33 [bbliss]
bbliss has joined #musicbrainz-devel
12:13:08 [luks]
luks has joined #musicbrainz-devel
12:29:18 [ijabz]
ijabz has joined #musicbrainz-devel
12:31:31 [axel_b]
axel_b has joined #musicbrainz-devel
12:36:51 [reosarevok]
reosarevok has joined #musicbrainz-devel
12:58:05 [wpl]
wpl has joined #musicbrainz-devel
13:22:01 [ijabz]
ijabz has joined #musicbrainz-devel
13:36:01 [ijabz_]
ijabz_ has joined #musicbrainz-devel
13:38:40 [reosarevok]
ocharles / warp: although this is a small issue because I guess almost nobody tries to do this, it's still an ISE and should be an easy fix if you're so inclined: http://tickets.musicbrainz.org/browse/MBS-4126
13:42:02 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
13:46:23 [ocharles]
reosarevok: it's doing the right thing
13:46:56 [ocharles]
hmm, status code 500 is wrong though, it's a client error
13:46:57 [reosarevok]
How is not working the right thing?
13:47:06 [reosarevok]
:/
13:47:10 [ocharles]
because you gave it bad parameters?
13:47:15 [ocharles]
what's it meant to do? guess what you meant?
13:47:27 [reosarevok]
I entered it normally via the Relate to... field
13:47:34 [reosarevok]
So it's not *me* who gave it bad parameters
13:47:43 [ocharles]
ok, then you need to provide steps for reproduction
13:48:04 [reosarevok]
The title says "Error in Relate to... from URL pages
13:48:04 [reosarevok]
", I thought it was clear enough
13:48:06 [ocharles]
i'm not quite following what's gone wrong, I guess
13:48:07 [reosarevok]
Ok, ok
13:48:17 [reosarevok]
Let me do that
13:48:19 [ocharles]
thanks
13:48:52 [reosarevok]
Go to http://musicbrainz.org/url/e2c35b9f-1433-4eed-ac86-0ffa0cc28fcb#relate_to and try to relate it to anything
13:48:56 [reosarevok]
That's all the step
13:49:03 [reosarevok]
I will put it in the ticket too though
13:49:12 [reosarevok]
(through Relate to...)
13:49:18 [ocharles]
oh right, that's odd
13:49:37 [reosarevok]
As I said, just putting url in the right place in the URL solves it
13:49:45 [reosarevok]
So I guess someone just forgot
13:51:28 [ocharles]
well, it's meant to be automatically figured out
13:51:32 [ocharles]
so a mapping somewhere is missing
13:51:56 [ocharles]
(one more place expressive typing would have caught a bug :P)
13:52:06 [ocharles]
though it's javascript, so it's not like an alternative exists
14:00:56 [navap]
ocharles: I think you're missing some of my commits in MeB's master.
14:02:58 [navap]
You're missing the three commits I pushed after your comment on github
14:03:01 [navap]
https://github.com/navap/metabrainz-server/compare/master...next
14:03:12 [ocharles]
hm
14:03:23 [ocharles]
git fetch doesn't show anything
14:03:37 [ocharles]
but git fetch navap does
14:03:37 [ocharles]
bah.
14:03:53 [ocharles]
pushed, hopefully that's got it
14:04:11 [navap]
Yup
14:04:18 [navap]
I love how fast the MeB server restarts.
14:04:48 [ocharles]
yea, I should profile musicbrainz-server some time and get that faster
14:05:16 [ocharles]
but i imagine it's just the overhead of having to wire everything up
14:05:21 [navap]
MeB restarts so fast I can save a file, alt-tab over to my brwoser and hit refresh right away
14:09:44 [navap]
What is the PAYPAL_BUSINESS definition used for?
14:15:18 [ocharles]
dunno, just copying what was there before
14:15:29 [ocharles]
people buying things off us, rather than donating, iirc
14:15:48 [navap]
metabrainz.org.uk though?
14:16:08 [ocharles]
oh, that's probably just me autopiloting my own tld :)
14:16:10 [ocharles]
(ocharles.org.uk)
14:16:29 [navap]
Ah :)
14:17:26 [ocharles]
fixed, thanks
14:50:31 [aylex]
aylex has joined #musicbrainz-devel
14:52:37 [luks]
luks has joined #musicbrainz-devel
15:02:23 [ocharles]
ffs, what is hosting coverartarchive.org?
15:15:32 [ocharles]
http://0.0.0.0:3000/release/04b3ef02-d9bb-47cd-8fb4-d4723eaff475/cover-art tada
15:15:34 [ocharles]
pending cover art
15:15:44 [ocharles]
oh wait... haha. *facepalm*
15:44:23 [ijabz]
ijabz has joined #musicbrainz-devel
16:07:49 [hawke_1]
hawke_1 has joined #musicbrainz-devel
16:24:53 [the_metalgamer]
the_metalgamer has joined #musicbrainz-devel
16:55:56 [Leftmost]
Leftmost has joined #musicbrainz-devel
17:06:34 [ocharles]
djce: the logs are full of rate limit warnings - are you aware of them?
17:06:45 [djce]
which logs?
17:07:20 [ocharles]
mb_server
17:07:23 [djce]
on?
17:07:24 [ocharles]
2012-01-05 16:08:03.232825500 [warning] GET http://musicbrainz.org/ws/1/release-group/38d1077e-c270-49a8-92ca-87e7eb8d9fe4?type=xml&inc=releases+artist caused a warning: send() on closed socket GEN0 at /home/musicbrainz/musicbrainz-server/script/../lib/MusicBrainz/Server/Data/RateLimiter.pm line 44.
17:07:42 [ocharles]
that's from pingu
17:07:43 [djce]
yes, that's the bug I believe I fixed in master before Christmas IIRC
17:07:46 [djce]
not yet rolled out
17:07:47 [djce]
AFAIK
17:07:48 [ocharles]
ahh
17:07:53 [ocharles]
I thought you put it on production, my bad
17:07:58 [ocharles]
warp: can we ship this? :)
17:12:57 [djce]
git branch --contains e5b295caa6c9959fa3efc1fb55ccab846fde16a8 -r
17:13:21 [ocharles]
yea, I just made an assumption, didn't actually check. my bad
17:13:21 [djce]
(not sure how to interpret that though because I'm not familiar with your use of branches for deployment)
17:13:49 [djce]
also 582ab3bfd11f1bd0f78a9a87635c13fbfb7adea8
17:14:17 [ocharles]
yea, I think we cherry picked that
17:14:35 [ruaok]
ruaok has joined #musicbrainz-devel
17:14:40 [djce]
so what branch does it need to be on to get to production?
17:15:03 [ocharles]
production
17:15:12 [djce]
just checking :-)
17:15:20 [ocharles]
but it's best to commit to master, and then cherry pick to production
17:15:49 [djce]
e5b295caa6c9959fa3efc1fb55ccab846fde16a8 doesn't seem to be on the production branch either
17:16:02 [djce]
unless I'm driving git wrong (quite possible)
17:16:23 [ocharles]
no, that's not on production - the last update was on the 22nd
17:16:28 [ocharles]
(as in proper update)
17:16:41 [ocharles]
i only cherry picked the user agent one as that was entirely flooding the logs
17:16:50 [ocharles]
really would like to just release today
17:17:13 [ruaok]
moin
17:17:18 [ruaok]
with beta sorted, we can release, right?
17:17:30 [djce]
* djce notices the local patch to lib/MusicBrainz/Server.pm - hope that doesn't go AWOL!
17:18:07 [ocharles]
djce: naw, I never do hard resets during an upgrade - usually stash, pull, then pop
17:18:20 [ocharles]
ruaok: i hope so. I set up beta again today using carton, works a treat
17:18:32 [ocharles]
cpan pain, away!
17:18:36 [djce]
That change probably belongs in git I guess. I don't think I committed it anywhere.
17:20:38 [ruaok]
ocharles: awesome.
17:20:49 [ruaok]
do you think we should try and get lolo up using carton?
17:21:03 [ocharles]
already done
17:21:12 [ruaok]
nice.
17:21:17 [ocharles]
all i've done is install perl deps though
17:21:25 [ocharles]
DBDefs and other things need looking at
17:21:31 [voiceinsideyou1]
voiceinsideyou1 has joined #musicbrainz-devel
17:21:36 [ruaok]
ok, so we still need nginx and fastcgi
17:21:45 [ruaok]
I already copied over DBDefs from astro.
17:21:57 [ruaok]
I can work on that stuff after coffee.
17:21:57 [ocharles]
ok, cool
17:22:07 [ocharles]
by fastcgi I guess you mean the daemontools service
17:22:07 [ruaok]
it would be nice to have another machine in production to raise our limits.
17:22:17 [ruaok]
yeah.
17:22:43 [djce]
ruaok: I suspect we actually have plenty of capacity already.
17:22:52 [djce]
What do we think our limiting factor might be?
17:23:04 [ruaok]
web servers.
17:23:17 [djce]
What aspect? cpu? memory? disk? net?
17:23:18 [ruaok]
but if your patches fix the performance of it, then we very well may.
17:23:18 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
17:23:36 [ruaok]
but, given that we have servers and bandwidth, we could consider allowing more hits for py73.
17:23:57 [ruaok]
and having more spare capacity would be nice.
17:24:06 [ruaok]
we could have servers ready to go and then just switch them off.
17:24:11 [ruaok]
and turn them on as we need them.
17:24:20 [djce]
Well, I'm just thinking of this graph:http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?View=-1&Template=1196205794.8081&Base=%2Fvar%2Fwww%2Fmrtg%2F%2Fasterix_load.rrd&Start=end+-+2+weeks&End=now&Mode=view
17:24:20 [ruaok]
EC2, but much more manual. :)
17:24:43 [djce]
or http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?View=-1&Template=1196205794.8081&Base=%2Fvar%2Fwww%2Fmrtg%2F%2Fasterix_load.rrd&Start=end+-+6+weeks&End=now&Mode=view
17:25:03 [djce]
that's the Proc::ProcessTable drop
17:25:08 [ruaok]
yep.
17:25:14 [ocharles]
that spike is so wtf
17:25:23 [ocharles]
impressive overall drop though
17:25:26 [djce]
I raised the global ratelimit recently, after removing proc::pt
17:25:31 [ruaok]
srsly. I saw that and nothing else spiking, and that was my reaction too.
17:25:39 [ruaok]
to 3K?
17:25:41 [djce]
yup
17:25:44 [ruaok]
k
17:25:45 [djce]
iirc
17:26:19 [djce]
3000req/10s
17:26:26 [ruaok]
* ruaok nods
17:28:07 [djce]
ocharles: I'm not sure I understand git well enough to work out why, but the Proc::PT stuff is not in master, but is in production.
17:28:19 [djce]
Don't know if that's deliberate or not.
17:28:26 [ocharles]
djce: I haven't done any commiting of that at all
17:28:32 [ocharles]
so I guess you only commited it to production
17:28:36 [ocharles]
oh wait
17:28:39 [ocharles]
yes, that is correct
17:28:48 [ocharles]
it's for debugging our production servers, so no need to put it into master
17:29:08 [ocharles]
I think we can just kill that code now
17:29:22 [ocharles]
I don't think it's actually been used since june
17:29:33 [ocharles]
ruaok: this is the "process now has x bytes free memory" thing
17:32:54 [ocharles]
ruaok: are you avail to drive proxies?
17:33:26 [axel_b]
axel_b has joined #musicbrainz-devel
17:38:58 [ruaok]
I am now
17:39:11 [ruaok]
you wanna release now?
17:40:15 [ruaok]
wow. its gone from 19C to 21C in the time I've been up. about half an hour.
17:40:18 [ruaok]
gonna be hot today
17:41:22 [ocharles]
yes please
17:41:31 [ocharles]
all ready here!
17:41:31 [ruaok]
ok
17:43:55 [ruaok]
asterix is out.
17:46:04 [ocharles]
ruaok: asterix done
17:46:22 [ruaok]
asterix back in
17:46:36 [djce]
* djce moves laptops. back soon.
17:46:42 [ruaok]
pingu going out, proceed when quiet
17:48:52 [ocharles]
sorry, mildly ballsed this one up lol, one sec
17:49:07 [ruaok]
lol
17:49:17 [ruaok]
mildly ballsed up. hah.
17:50:06 [ocharles]
ruaok: alright, asterix back
17:50:17 [ruaok]
pingu?
17:50:25 [ocharles]
uhh, that one yea :)
17:50:39 [ocharles]
right server, typed the wrong name in irc
17:50:41 [ocharles]
phew
17:50:49 [ruaok]
lol
17:51:06 [ruaok]
pingu in, astro going out. proceed when quiet
17:51:52 [ocharles]
mmmm, these logs are looking much nicer
17:52:07 [ruaok]
yay, quiet logs!!
17:52:22 [ocharles]
tail -f /usr/local/mb_server-fastcgi/log/main/current | tai64nlocal | grep -v 'FastCGI:' # will give you quiet logs
17:53:15 [ocharles]
ruaok: ok, astro done
17:53:32 [ruaok]
astro coming back.
17:54:55 [ruaok]
nikki: you around?
17:55:02 [nikki]
yes
17:55:09 [ruaok]
hi!
17:55:18 [ruaok]
we should continue triaging CAA issues/
17:55:22 [nikki]
sure
17:55:25 [ocharles]
ok, I'm going for a jog then I'll do the blog post
17:55:27 [ocharles]
so bbiab in 30 minutes
17:55:31 [ruaok]
will you be around for a bit?
17:55:39 [ocharles]
bbi 30 minutes I guuess that should be :)
17:55:39 [ruaok]
say in 30 minutes? :)
17:56:39 [djce]
djce has joined #musicbrainz-devel
17:57:33 [ruaok]
djce: http://stats.musicbrainz.org/mrtg/drraw/drraw.cgi?Mode=view;Template=1196205794.8081;Base=%2Fvar%2Fwww%2Fmrtg%2F%2Fastro_load.rrd
17:57:46 [ruaok]
looking at the past month graph...
17:57:57 [ruaok]
what happened a the beginning of week 52?
17:58:10 [ruaok]
oh wait, that was the rate limiting.
17:58:25 [ruaok]
and then post spike was your process table fix.
17:58:41 [djce]
yup. big drop (block), medium rise (throttling instead),
17:58:50 [djce]
two big spikes, one on astro and one on asterix
17:58:50 [ruaok]
ok.
17:58:55 [ruaok]
and the BBC is done hitting our servers?
17:59:00 [djce]
(both unexplained)
17:59:08 [djce]
and then a big drop (proc::pt).
17:59:27 [djce]
* djce swears at firefox
17:59:36 [djce]
I'll let you know when I have a browser
17:59:49 [ruaok]
mrtg says the rate has dropped to 0
18:00:03 [djce]
oh, that'll be a bug I think
18:00:05 [djce]
in the monitoring
18:00:11 [ruaok]
ha.
18:00:11 [djce]
yesterday was it?
18:00:25 [ruaok]
yes
18:01:01 [ruaok]
http://stats.musicbrainz.org/mrtg/95th-percentile/201201.png
18:01:11 [djce]
that's when I deployed the new lives-in-git ratelimit-server.
18:01:12 [ruaok]
tsk tsk. who caused that 25mbit spike?
18:01:47 [djce]
wow. pretty big spike.
18:01:53 [ruaok]
ya.
18:02:09 [ruaok]
caused no harm, but its an issue we shouldn't have
18:02:24 [djce]
unless it's a monitoring glitch maybe...
18:03:31 [djce]
* djce wonders what's on port 19
18:03:57 [djce]
carl. hmmm....
18:04:01 [ruaok]
woah.
18:04:04 [ruaok]
odd.
18:04:54 [djce]
ah scooby.
18:05:15 [djce]
both ftp and rsync should be limited, iirc. but http isn't.
18:05:28 [ruaok]
oh whoops.
18:06:13 [djce]
I'm hoping to introduce proper traffic shaping soon.
18:08:57 [ruaok]
do we have a stop-gap solution for rika in the meantime.
18:09:20 [ruaok]
I'm holding off giving ianmcorvidae access to the machine until we have some throttling in place
18:14:11 [ruaok]
http://tech.slashdot.org/story/12/01/05/0037233/nginx-overtakes-microsoft-as-no-2-web-server
18:14:23 [ruaok]
wow. nginx is now the no 2 web server.
18:21:37 [djce]
* djce fixes the ratelimit-server bugs
18:35:41 [reosarevok]
ocharles, are you making a blog post?
18:40:43 [kepstin-laptop]
hey guys - I think something's gone wrong with the release relationships code. The server's not displaying the composer/lyricist (or any other work credits) any more.
18:41:47 [ocharles]
reosarevok: I will be now
18:41:54 [ocharles]
kepstin-laptop: got a link?
18:42:03 [kepstin-laptop]
http://musicbrainz.org/release/081f7459-dc56-4f7f-951b-78219f9e503f for example
18:42:09 [kepstin-laptop]
has lyricist/composer on all works
18:42:14 [ocharles]
hmm
18:42:21 [ocharles]
* ocharles looks into it before blagging
18:42:50 [reosarevok]
If you hotfix that, you could also hide the URLs for releases (those are shown in the sidebar already9
18:42:51 [reosarevok]
*)
18:43:19 [nikki]
not all of them, and you can't edit them from the sidebar
18:43:23 [reosarevok]
Meh
18:43:34 [reosarevok]
Ok, I'll live with the bloat for now :p
18:43:36 [ocharles]
reosarevok: no, report that
18:44:12 [nikki]
I'm surprised you can even see them with your bloated tracklists :P
18:44:28 [luks]
we should probably have a url editor page, where you can edit all urls for a particular artist/release
18:44:33 [luks]
and then link that from the sidebar
18:44:52 [nikki]
* nikki wonders if luks is going to implement it ;)
18:45:10 [luks]
I might :)
18:46:02 [luks]
I'd like one for band members too
18:46:32 [reosarevok]
Those are not even in the sidebar now, so it's double work :p
18:47:09 [luks]
but they should :)
18:47:22 [luks]
see #mb
18:47:26 [nikki]
I'm not sure I'd do one just for band members. being able to edit all artist-artist relationships makes more sense to me (could be a section on the page for members though)
18:47:33 [ocharles]
ooo, sneaky little bug
18:47:34 [reosarevok]
* reosarevok wouldn't argue against it - as long as they are hideable
18:47:50 [ocharles]
no type safety is gonna catch this one!
18:47:50 [ocharles]
:P
18:47:52 [reosarevok]
(if not, the members for some of those weird bands nikki edits would take 5 screens)
18:48:01 [nikki]
haha, true
18:48:03 [luks]
nikki: general AR editor is going be too complicated
18:48:04 [hawke_1]
luks: Isn’t the band members thing basically the same as ocharles’ relationship editor?
18:48:19 [ijabz_]
ijabz_ has joined #musicbrainz-devel
18:48:22 [luks]
but these special-purpose pages could be much simpler
18:49:33 [luks]
but then, I'd also like relationships to become hidden and be visible only as 'links', 'credits', etc.
18:49:55 [reosarevok]
�?
18:50:03 [ocharles]
luks: i'm working on said general ar editor
18:50:20 [reosarevok]
Hidden how?
18:50:23 [ocharles]
but not a url editor, go ahead with that one :)
18:50:38 [nikki]
reosarevok: presumably fewer tabs saying "relationships" for a start
18:50:49 [ocharles]
reosarevok: most relationships can be better displayed contextually
18:50:49 [luks]
reosarevok: as in you don't know how it's stored
18:51:01 [ocharles]
that's why I'm hesistant to add relationships to bookbrainz the same as musicbrainz
18:51:01 [luks]
reosarevok: you only see links, credits, band members, etc.
18:51:07 [ocharles]
because we'll end up designing into the same problem
18:51:11 [luks]
the storage is good
18:51:14 [luks]
but the presentation is not
18:51:14 [ocharles]
yea
18:51:21 [reosarevok]
As long as it doesn't become harder to edit, I couldn't care less
18:51:33 [reosarevok]
Just make sure you don't make it even more complicated :p
18:51:35 [luks]
it was nice at the begining when we just experimented with the data
18:51:43 [ocharles]
where's ruaok?
18:51:44 [luks]
but the structure is more or less static now
18:51:57 [luks]
we only add specific types that belong to some existing 'category'
18:52:02 [ocharles]
warp: ping, but I guess you aren't there
18:53:09 [reosarevok]
luks: given that I did ask to separate visually performing and technical credits, I'm all in favour of better presentation
18:53:21 [reosarevok]
As I said, as long as it doesn't make editing harder
18:53:47 [luks]
reosarevok: I believe that discogs has more credits specifically because they are entered as credits, not some generic relationships
18:53:59 [luks]
people understand that easily
18:54:09 [reosarevok]
Don't they also ask for them to be added at the same time as the release?
18:54:15 [luks]
yes
18:54:21 [reosarevok]
That sounds more like it :p
18:54:29 [luks]
but you just say 'composer' 'X'
18:54:51 [reosarevok]
Sure
18:55:00 [luks]
the point is that you can't have all the options in the release editor
18:55:02 [reosarevok]
But all this seems like it makes it harder to work in nice batches :p
18:55:08 [luks]
but you can have these special-purpose fields
18:56:02 [ruaok]
ruaok has joined #musicbrainz-devel
18:56:05 [reosarevok]
(say, now I'll open 30 work pages, and in all I can press the same buttons which are in the same place, and in the resulting page expect to find the stuff in the same region of the page, etc)
18:56:31 [reosarevok]
(so I can easily move through all of those tabs doing the same n steps sequencially)
18:56:49 [reosarevok]
With a specific multi-purpose editor for everything that sounds harder
18:56:51 [luks]
what are you oding with those buttons?
18:57:21 [reosarevok]
Relating the same composer to 30 works for example, in different dates
18:57:49 [reosarevok]
(like, 10 works have a date, 15 a second date, and the last 5 have 5 different dates)
18:57:56 [luks]
I don't see why it would be different
18:58:35 [luks]
I said it would be special-purpose editor, not multi-purpose editor :)
18:58:39 [reosarevok]
I can still do a good amount of that by pressing "use in relationship", and mechanically moving through all the pages pressing "use in a relationship" + setting the Ar to "composer"
18:58:43 [luks]
it should be easier, if anything :)
18:58:50 [reosarevok]
Ideally, sure
18:59:01 [reosarevok]
* reosarevok remembers the new RE should be easier, if anything :p
19:00:30 [ocharles]
ruaok: oh you're back
19:00:35 [ocharles]
we need to deploy a hotfix
19:00:41 [ruaok]
yep, ready to get that knocked out.
19:00:46 [ocharles]
kewl
19:00:47 [ruaok]
oh?
19:00:54 [reosarevok]
luks: Something that works well on paper doesn't imply it can be easily made to work in practice
19:00:56 [ruaok]
I thought we never had to do that again, now that we have beta?
19:01:07 [ocharles]
hey, warp said that
19:01:07 [reosarevok]
(we should move to #mb I guess)
19:01:08 [ocharles]
not me :)
19:01:25 [reosarevok]
ruaok: remember ocharles wasn't even fully using beta yet
19:01:39 [ruaok]
yep, that's who that comment was directed at. :)
19:01:55 [ocharles]
less arguing over crappy qa procedures, more hotfixing!
19:01:55 [ocharles]
:P
19:02:06 [ruaok]
* ruaok should've made that more clear
19:02:13 [ruaok]
* ruaok logs into carl
19:02:39 [ocharles]
i should be using beta now that we have really easy updating
19:02:54 [ocharles]
need to update mah scriptz
19:03:55 [ruaok]
ready?
19:03:57 [ocharles]
yep
19:04:14 [ruaok]
asterix going out, proceed when quiet
19:05:30 [hawke_1]
Wow, that “Found in n user collections” is really subtle. :-(
19:05:45 [ocharles]
ruaok: asterix done
19:05:57 [ruaok]
coming back in
19:06:11 [ocharles]
hawke_1: hopefully we'll get beta official announced soon, and I'm hoping to mashup the "in beta testing" issues from jira into the top of the page
19:06:12 [ruaok]
pingu out
19:07:10 [reosarevok]
hawke_1: how do you want it, blinking and at size 30? :p
19:07:14 [ocharles]
ruaok: pingu back
19:07:16 [hawke_1]
reosarevok: Yes please!
19:07:26 [hawke_1]
reosarevok: <blink> for life!
19:07:34 [ruaok]
pingu coming back
19:07:34 [ocharles]
<marquee>!
19:07:54 [ruaok]
astro going out.
19:08:06 [hawke_1]
reosarevok: Seriously: No, but it currently blends in with the “add to [collection]” links
19:08:18 [hawke_1]
reosarevok: Maybe not a problem if you only have the one “My collection”
19:08:19 [reosarevok]
hawke_1, let's move to #musicbrainz fo rit
19:08:21 [reosarevok]
*for it
19:08:24 [ocharles]
patches welcome
19:09:00 [ocharles]
you guys really do enforce the idea of "no matter what you write, they will complain" :P
19:09:04 [ocharles]
ruaok: astro back
19:09:24 [ruaok]
astro coming back.
19:09:27 [reosarevok]
ocharles: that's what users do!
19:09:46 [ruaok]
ocharles: navap has caught up on the things he is doing for me.
19:09:58 [ruaok]
you and warp should rely on him for UI issues.
19:10:24 [ocharles]
he did this feature
19:10:27 [ocharles]
so...
19:10:27 [ruaok]
both for fixing shit and for making new shit work right.
19:10:30 [ruaok]
oh!
19:10:31 [ocharles]
:P
19:10:54 [ruaok]
well, it was a good thought. :)
19:11:03 [ocharles]
* ocharles takes offence
19:11:11 [ruaok]
?
19:11:18 [ocharles]
bad ui, assume it's ocharles
19:11:19 [ocharles]
I GET IT
19:11:20 [ocharles]
:P
19:11:38 [ocharles]
anyway, re caa stuff, not a huge amount to do there, I put everything in the 3mo bucket
19:11:40 [ruaok]
sorry, that wasn't my intent. you complained about people complaining, I thought you'd done it.
19:11:46 [ocharles]
i know, i'm only teasing
19:11:48 [ocharles]
and it's true too
19:11:49 [ocharles]
lol
19:11:49 [ruaok]
but all the tickets are clear now?
19:11:55 [ruaok]
heh.
19:11:56 [ocharles]
clear, but not all actionable
19:12:04 [ocharles]
well, one problem anyway
19:12:11 [ocharles]
I think people want pending artwork (which we now have) to link to the edit
19:12:14 [ruaok]
because they are blocked on various things or unclear?
19:12:24 [ocharles]
but this means the filename needs to have the edit number in
19:12:29 [ocharles]
but we don't have that until the upload is complete
19:12:41 [ocharles]
so we either don't have that feature, or we immediately move the file after upload, which is a bit of pita, but doable
19:12:56 [ruaok]
hmmm. modbot is on about a lock error,.
19:14:18 [ruaok]
is there anything else that needs discussing on the CAA front?
19:14:28 [ocharles]
hum
19:14:41 [ruaok]
I'm going to do your pull request and see if I can deploy into cherrypy later today.
19:14:55 [ruaok]
and then doc and all the other things.
19:14:55 [ocharles]
I did manually patch whatever was on hobbes with it
19:14:57 [ocharles]
so it does work atm
19:15:04 [ocharles]
but I couldn't figure out how you deployed it
19:15:05 [ruaok]
ok.
19:15:13 [ocharles]
so it's hand patched, and I killed some random processes until it worked
19:15:18 [ruaok]
lol.
19:15:25 [ocharles]
the tickets look clear to me on a quick eyeball over my open bugs list
19:15:34 [ruaok]
ok, then.
19:15:40 [ocharles]
also... reosarevok, nikki, hawke_1, luks, ruaok, warp -- scheduling?
19:15:45 [reosarevok]
Ok
19:15:59 [ruaok]
scheduling what? general bug triage?
19:16:01 [ocharles]
yea
19:16:05 [ocharles]
I'm free until 9UTC
19:16:11 [ocharles]
then it's Go + curry time :)
19:16:12 [ruaok]
I was ready to triage, so bring it!
19:16:23 [ocharles]
reosarevok: you wanna drive?
19:16:32 [ocharles]
the reports are a bit out of date, but there's enough info to work off
19:16:41 [ocharles]
(rather than killing my server for 5 minutes while it indexes :P)
19:17:06 [reosarevok]
:p
19:17:09 [reosarevok]
Ok then
19:17:18 [reosarevok]
* reosarevok opens them
19:18:02 [reosarevok]
So, nikki hawke_1 luks warp and the rest, who is around?
19:18:02 [ocharles]
only 750 issues to go!
19:18:02 [ocharles]
P
19:18:03 [ocharles]
:P
19:18:14 [luks]
not me :)
19:18:18 [nikki]
hi
19:18:22 [reosarevok]
Ok
19:18:42 [reosarevok]
ocharles, ruaok, nikki and me seem enough to start (and maybe not-luks :p)
19:18:44 [hawke_1]
I’m here. :-)
19:18:46 [reosarevok]
[MBS-1989] Use icons to identify add/remove/edit/merge edits easily863
19:19:05 [reosarevok]
* reosarevok still can't get why people have so huge problems reading
19:19:09 [ocharles]
lol
19:19:12 [reosarevok]
But hey, if it doesn't hurt...
19:19:21 [ocharles]
the majority is 3, i think that's doable
19:19:30 [ocharles]
of course, people will argue the icons aren't clear enough, but whatever
19:19:33 [nikki]
* nikki doesn't agree with adding icons
19:19:43 [hawke_1]
I constantly miss “remove” thinking its an add
19:19:56 [hawke_1]
and I’ve seen lots of comments to that effect after a no-vote
19:20:01 [ocharles]
I think the ticket could be generalised to "make those categories distinct"
19:20:02 [reosarevok]
:p
19:20:15 [nikki]
ocharles: I think I said something like that on the ticket
19:20:35 [reosarevok]
I'd be kinda OK with colors or icons I guess
19:20:36 [nikki]
the problem is that they need distinguishing, we need to find a solution that works without blinding luks like my rainbow edits ;)
19:20:41 [ruaok]
I'd prefer the colors approach over icons
19:20:44 [reosarevok]
I really don't see the point, but still
19:20:47 [reosarevok]
luks?
19:20:52 [hawke_1]
ruaok: don’t forget the color-blind though
19:20:56 [nikki]
I'm sure he said it's too bright for him
19:21:07 [reosarevok]
hawke_1, colorblind can read :p
19:21:15 [ocharles]
that's ok, we can figure out 4 colours in 3 months
19:21:16 [reosarevok]
It's not as if we *didn't* say anything
19:21:20 [ocharles]
that I'm pretty confident about
19:21:24 [ocharles]
so are we ok with 3mo on this?
19:21:25 [luks]
I'mnot against colors in general, just against nikki's choice of colors :)
19:21:28 [reosarevok]
Ok
19:21:31 [hawke_1]
reosarevok: :-p just saying icons are helpful too.
19:21:33 [reosarevok]
I guess 3 is fine then?
19:21:39 [ocharles]
hawke_1: kick up that discussion on the ticket
19:21:39 [nikki]
luks: ahh. any suggestions that work better for you?
19:21:50 [luks]
not really
19:21:57 [reosarevok]
nikki, luks: on the ticket please :)
19:21:58 [ocharles]
on the ticket please people, lets focus on getting through this massive queue...
19:22:00 [ocharles]
ta
19:22:03 [reosarevok]
[MBS-3672] Remove the deprecated Live Sound Engineer relationship785
19:22:16 [reosarevok]
As per http://wiki.musicbrainz.org/Live_Sound_Engineer_Relationship_Type the relationship has been deprecated. A script should be run to convert all cases of this into just "Sound Engineer", and the relationship should be removed once it is empty.
19:22:19 [reosarevok]
Doesn't sound too hard
19:22:23 [ocharles]
yea, that's fine
19:22:31 [ocharles]
3 mo is fine there, to show we're responsive to style and all that :)
19:22:43 [ocharles]
(yes, i've seen the created date)
19:22:46 [reosarevok]
heh, only a year and something late
19:22:46 [reosarevok]
:p
19:22:46 [ruaok]
fine
19:22:47 [reosarevok]
Ok
19:22:48 [reosarevok]
[MBS-3429] Secondary ISE while inserting edit note obscures primary ISE218
19:22:56 [reosarevok]
still as unclear as always
19:23:04 [ocharles]
yea, skip it
19:23:06 [reosarevok]
warp was going to look at this one, right?
19:23:12 [ocharles]
I think it's gonna get closed as a wontfix eventually
19:23:16 [reosarevok]
[MBS-848] When viewing a release group with only 1 release, forward to the release567
19:23:20 [reosarevok]
Strongly disagree
19:23:28 [reosarevok]
Navigation should be better but this is not the way
19:23:41 [ocharles]
heh, my ticket
19:23:43 [luks]
I think my ticket is a better solution
19:23:46 [nikki]
I'd agree with showing more info on the release group
19:23:54 [ocharles]
luks: the "recordings on all releases" one?
19:23:56 [luks]
the one about the shared recordings
19:23:57 [nikki]
rather than redirecting
19:24:01 [ocharles]
i'm fine with that
19:24:02 [luks]
yes
19:24:12 [ocharles]
ok, i'll close as wontfix and add a resolved by your ticket
19:24:14 [reosarevok]
Oh, that one
19:24:14 [ruaok]
forwarding has been deprecated in other parts of the site, so we should not do that here.
19:24:15 [reosarevok]
Yes
19:24:24 [ocharles]
ruaok: true
19:24:29 [ocharles]
ok, next
19:24:31 [reosarevok]
* reosarevok doesn't like "If we want a smarter way to display release groups, I'd go with the way SoundUnwound does it"
19:24:34 [reosarevok]
though
19:24:40 [reosarevok]
(which I thought you meant)
19:24:46 [reosarevok]
[MBS-1850] Edit migration: Don't build editing history for 'Various Artists'118
19:24:49 [reosarevok]
a bit too late? :)
19:25:08 [ocharles]
it still don't see why not
19:25:12 [ocharles]
anyway, unsched
19:25:15 [reosarevok]
Ok
19:25:26 [ruaok]
I'm ok with wontfix
19:25:35 [reosarevok]
[MBS-1679] Don't display Merge Process in release editor327
19:25:40 [reosarevok]
I agree with this one
19:25:47 [reosarevok]
(as in, not a wontfix)
19:25:53 [reosarevok]
But I agree it's not a priority either
19:26:10 [nikki]
unsched?
19:26:12 [ocharles]
unsched for me
19:26:15 [reosarevok]
Most likely, yeah
19:26:18 [ruaok]
k
19:26:21 [reosarevok]
If someone wants to do it, they can
19:26:32 [ruaok]
navap>
19:26:32 [reosarevok]
[MBS-2159] Artist credit "toggle" should be consistent286
19:26:44 [ruaok]
removing clutter in the RE should be a goal.
19:26:56 [reosarevok]
* reosarevok didn't think [MBS-2159] Artist credit "toggle" should be consistent286 was a problem
19:27:00 [reosarevok]
But hey, maybe it is
19:27:02 [reosarevok]
12 sounds fine
19:27:06 [reosarevok]
I guess
19:27:11 [ocharles]
sounds cosmetic?
19:27:18 [ocharles]
if so, I'd be more inclined to vote 12
19:27:20 [ocharles]
sorry unsched*
19:27:21 [ruaok]
navap.
19:27:33 [nikki]
* nikki didn't think it was a problem either
19:27:43 [nikki]
navap reported it, he can fix it if it bothers him ;)
19:27:46 [ruaok]
if we agree its not a problem, the lets wontfix it.
19:27:54 [ocharles]
ruaok: theres' something that can be fixed
19:27:56 [ocharles]
it's just not important
19:27:58 [ocharles]
so unschedule
19:28:04 [ruaok]
k
19:28:04 [ocharles]
imo
19:28:10 [reosarevok]
ruaok: 10 people voted not unsched, so it *is* a problem for someone I guess
19:28:15 [reosarevok]
It just seems so terribly minor
19:28:17 [reosarevok]
unsched is fine
19:28:21 [ocharles]
hmm
19:28:22 [ocharles]
true
19:28:26 [ocharles]
change that to 12 then)
19:28:28 [ocharles]
:)
19:28:30 [reosarevok]
Tsk
19:28:31 [reosarevok]
Fiiiine
19:28:32 [reosarevok]
[MBS-908] Parser cannot handle commonly used punctuation other than period for tracknumber547
19:28:32 [ruaok]
just FYI: I'm trying to integrate navap more into the dev process.
19:28:47 [ruaok]
so, lets make use of him for UI related things.
19:28:52 [nikki]
at least 12 because it's the release editor
19:28:58 [ruaok]
lol
19:28:59 [ruaok]
yea.
19:29:04 [ocharles]
ruaok: sounds good, you should point him at the buckets
19:29:10 [reosarevok]
Guise!
19:29:10 [reosarevok]
[MBS-908] Parser cannot handle commonly used punctuation other than period for tracknumber547
19:29:13 [reosarevok]
:p
19:29:19 [ruaok]
ocharles: I have.
19:29:21 [ocharles]
i'm ok with 12, but votes there lean to 3
19:29:29 [hawke_1]
should be trivial, no?
19:29:30 [ruaok]
I just want you to be aware that you can task him.
19:29:37 [ocharles]
ok :)
19:29:43 [ocharles]
hawke_1: trivial != worth my time
19:29:43 [reosarevok]
hawke_1, should be
19:29:50 [reosarevok]
Though, in the RE... who knows
19:29:52 [ocharles]
or warps
19:29:54 [ruaok]
12
19:30:03 [ocharles]
i'm ok with 12 or 3 though
19:30:06 [reosarevok]
It is annoying, but I guess 12 is enough
19:30:13 [reosarevok]
12 + major maybe?
19:30:19 [hawke_1]
12/3, either way is fine by me.
19:30:20 [reosarevok]
So it gets done soon after the 3 stuff
19:30:26 [ocharles]
ok, 12 + major
19:30:33 [reosarevok]
[MBS-2121] Deleting track/row in advanced tracklist editor while artist credits "dialog" is open leaves it stuck755
19:30:39 [reosarevok]
that one sounds pretty bad
19:30:53 [reosarevok]
Oh, wait
19:30:57 [reosarevok]
It gets the dialog stuck
19:30:59 [reosarevok]
Not the RE
19:31:04 [reosarevok]
Then it's bad but not terrible
19:31:06 [ocharles]
either way, sounds 3
19:31:10 [reosarevok]
Yeah
19:31:11 [ruaok]
3
19:31:31 [reosarevok]
[MBS-684] TOC lookup displays too little release info774
19:31:38 [reosarevok]
This is very bad
19:31:45 [reosarevok]
But I don't know if it is doable as 4
19:31:47 [reosarevok]
*3
19:32:02 [reosarevok]
Basically, right now our disc ID submissions are mostly worthless
19:32:03 [ocharles]
mmmm, it's just about adding more information to a template right?
19:32:06 [ruaok]
lots of votes too.
19:32:12 [nikki]
it's a complete pain for anyone trying to add disc ids to the right release
19:32:15 [nikki]
3+navap?
19:32:17 [ruaok]
navap!
19:32:23 [ruaok]
* ruaok nods at nikki
19:32:29 [ocharles]
ok, 3
19:32:52 [reosarevok]
[MBS-1178] Relationship view needs paging.475
19:32:54 [ruaok]
how can we make a suggested list of things for navap?
19:33:05 [reosarevok]
ruaok: assign it to him :p
19:33:15 [reosarevok]
He can always refuse and unassign later if he feels it's too hard
19:33:17 [ocharles]
assign it to him is one option, but I still like leaving everything unassigned
19:33:27 [ruaok]
reosarevok: what ocharles said.
19:33:28 [ocharles]
when he does work, all you have to do is find tickets unassigned, or assigned to you
19:33:35 [ocharles]
clear your own tickets first, then chose something you think you can work on
19:33:36 [ruaok]
thus, how do we make this clear to him?
19:33:45 [ocharles]
well hopefully he can just develop that intuition
19:33:50 [ruaok]
ocharles: the latter part is hard.
19:33:57 [ocharles]
i know, but if he's stuck, he can just ask
19:34:03 [ruaok]
esp if we already did the work of id'ing tickets for him.
19:34:04 [ocharles]
and I think eventually he'll start to gain confidence
19:34:15 [ruaok]
ocharles: and then you need to spend more time finding things?
19:34:26 [ruaok]
thats silly. that work has already been done. lets not do it again.
19:34:42 [ocharles]
well then assign it to him I guess, I was just more going to work at his pace
19:34:53 [ocharles]
if he's got 5 things assigned to him due in a week, we risk missing deadlines
19:35:04 [ocharles]
if I have to step in and take over UI at that point, I might also miss my deadlines
19:35:10 [ocharles]
if everything is unscheduled, it's a lot more dynamic
19:35:14 [ruaok]
well, I'm not keen on assiging it to him if that flauts the process.
19:35:29 [reosarevok]
What about we deciding this post-scheduling? :p
19:35:31 [ocharles]
i just worry we lump loads there, and it just piles up
19:35:39 [ocharles]
c.f. me with 600 tickets before we sorted this mess out :)
19:35:41 [reosarevok]
Maybe... like, asking him? :p
19:35:50 [ruaok]
ok, lets proceed.
19:35:52 [reosarevok]
[MBS-1178] Relationship view needs paging.475
19:35:57 [ocharles]
email after the meeting would be fine I think
19:35:58 [nikki]
ocharles: well it didn't help that you were the default assignee for almost everything :P we're just assigning certain things to him
19:36:03 [ocharles]
"Please take what you think you can manage"
19:36:20 [ocharles]
reosarevok: 12
19:36:33 [reosarevok]
Yeah
19:36:35 [ruaok]
* ruaok takes a minute to start a list for navap
19:36:48 [reosarevok]
With our current paging this would be from the frying pan into the fire
19:36:50 [ocharles]
i'm hoping it only needs paging because of the sheer amount of time it takes, and fixing the speed might even solve the ticket
19:36:55 [reosarevok]
Let's make pagination not suck first :p
19:36:56 [ocharles]
+1
19:37:18 [reosarevok]
12 then?
19:37:23 [ocharles]
yea
19:37:28 [reosarevok]
[MBS-2637] Ability to search, filter works and merge related works into one473
19:37:45 [reosarevok]
AKA "making the works list useful"
19:37:59 [ocharles]
heh
19:38:08 [ocharles]
well, we want to fix paging in 12months, so I'd say 12 mo
19:38:12 [luks]
fixed by http://tickets.musicbrainz.org/browse/MBS-3266 ?
19:38:18 [nikki]
* nikki thinks there's several tickets in that ticket
19:38:24 [luks]
well, not the grouping part
19:38:26 [luks]
but filtering
19:38:26 [reosarevok]
luks: *works*
19:38:38 [reosarevok]
Works have no ACs
19:38:42 [reosarevok]
nikki, agreed
19:38:50 [nikki]
grouping and filtering are two separate things, so I would split the ticket first
19:39:00 [ocharles]
i think maybe paging should be the next major focus after caa
19:39:00 [reosarevok]
Agreed
19:39:04 [reosarevok]
With nikki
19:39:05 [luks]
reosarevok: the ticket I linked it about filtering in general
19:39:07 [reosarevok]
Dunno with ocharles
19:39:21 [reosarevok]
luks, the ticket is mine and is called " Allow filtering by artist credit
19:39:22 [reosarevok]
"
19:39:22 [ocharles]
anyway, 12?
19:39:27 [reosarevok]
Is it really general? :p
19:39:31 [reosarevok]
ocharles, yes please
19:39:32 [luks]
reosarevok: I'm not good at entering tickets :)
19:39:36 [reosarevok]
* reosarevok really wants this
19:39:42 [luks]
oh, it's yours
19:39:46 [luks]
I thought it's mind
19:39:54 [luks]
mine
19:40:29 [reosarevok]
luks, especially from the area this comes (classical) the needs are fairly different IMO
19:40:33 [reosarevok]
Well, we'll see
19:40:34 [reosarevok]
[MBS-2255] Create a report to show stuff that's linked to Various Artists, but may be an incorrect link295
19:40:52 [reosarevok]
nikki says this is covered by search
19:40:59 [ocharles]
a report would be nice though
19:41:06 [reosarevok]
Yeah
19:41:10 [reosarevok]
But not your priority
19:41:13 [nikki]
I think we need a page which lists searches that are like reports
19:41:20 [reosarevok]
hrgjjfdjfjf / JW can do it
19:41:21 [nikki]
instead of making reports for things we can easily do in the search
19:41:31 [reosarevok]
nikki: it would be good if it was a report once we can whitelist stuff in those
19:41:38 [nikki]
(the search is updated every 3 hours too)
19:41:40 [ocharles]
nikki: with report filtering by subscriptions, they become more useful
19:41:56 [ocharles]
anyway, argue about that later :) i'm not sure just how urgent this is
19:41:58 [ruaok]
+1 hrgrmgr
19:42:02 [ocharles]
but votes say 12, so i'd be ok with that
19:42:03 [nikki]
not very urgent :P
19:42:06 [reosarevok]
12 is fine
19:42:14 [nikki]
* nikki would say unsched until we have filtering reports :P
19:42:19 [reosarevok]
unsched might even be fine too, but after all this is an error in our data
19:42:24 [ocharles]
nikki: that's due in februrary
19:42:49 [nikki]
fine, fine
19:42:58 [ocharles]
well if you want unsched, I won't argue!@
19:43:00 [ocharles]
less work :D
19:43:05 [reosarevok]
12 is fine
19:43:06 [reosarevok]
[MBS-2228] Add release format to "release information"067
19:43:16 [reosarevok]
I don't really agree with hawke_1 here
19:43:27 [reosarevok]
Although I do agree it's maybe slightly not obvious now
19:43:44 [luks]
isn't it there already?
19:43:50 [reosarevok]
luks: in the RE
19:43:59 [reosarevok]
(as in, allow it to be set from the first page)
19:44:02 [reosarevok]
As I said, I don't agree :p
19:44:02 [luks]
oh
19:44:08 [ocharles]
i'd say wontfix personally
19:44:17 [hawke_1]
SCREW YOU GUYS! ;-)
19:44:22 [ocharles]
lol
19:44:32 [hawke_1]
There was another ticket related to that, IIRC
19:44:32 [reosarevok]
hawke_1, is there a way that would make it less bad while keeping it where it is?
19:45:10 [ocharles]
I say unsched
19:45:11 [nikki]
for me the main problem I see is people getting confused with status/packaging when adding digital releases, otherwise it seems to be fine on the tracklist tab
19:45:34 [reosarevok]
Well, then those should be clearer maybe?
19:45:42 [hawke_1]
reosarevok: Not sure…I guess the problem is that I feel like physical stuff should all be in one place
19:45:43 [ocharles]
that's a different issue
19:45:44 [reosarevok]
* reosarevok says unsched + discuss in the ticket
19:45:48 [ocharles]
+1
19:45:56 [hawke_1]
Works for me
19:45:56 [ruaok]
+1
19:45:57 [reosarevok]
[MBS-377] Allow querying by relationship type177
19:46:09 [reosarevok]
Obviously, a lot of voters don't use the ws at all
19:46:11 [reosarevok]
So this makes sense
19:46:16 [reosarevok]
I'd say 12 is fine
19:46:32 [ruaok]
fine
19:46:47 [ocharles]
hm
19:46:54 [ocharles]
not sure about in the next 12months
19:46:59 [ocharles]
doesn't really match any of our other focuses
19:47:01 [reosarevok]
Sounds hard?
19:47:12 [ocharles]
just disconnected from everything else we're looking at
19:47:21 [reosarevok]
Well, it matches our "letting people query our info from the ws" focus
19:47:27 [reosarevok]
which is the only real focus of the ws :p
19:47:32 [ocharles]
we don't have other tickets like that in 12mo I mean
19:47:43 [ocharles]
not sure whether that's a huge problem or not, but we're already past 100
19:47:45 [reosarevok]
* reosarevok doesn't know
19:47:54 [ocharles]
what do people think about unsched?
19:48:06 [ruaok]
given that it has few votes, 12/unsched for me
19:48:06 [reosarevok]
nikki?
19:48:07 [ocharles]
ruaok: with threescale soon, maybe we should sugar p the ws?
19:48:12 [ocharles]
up*
19:48:14 [reosarevok]
(you just imported it, sure, but...)
19:48:20 [nikki]
hmm
19:48:28 [ruaok]
ocharles: lets just get that done and then we'll see.
19:48:35 [ocharles]
alright
19:48:40 [nikki]
would it be possible in the search?
19:48:42 [ocharles]
(and i'm awaiting feedback from you on that ticket :P)
19:48:48 [ruaok]
ocharles: I know.
19:48:53 [ocharles]
ok, kewl
19:48:53 [ruaok]
nikki: ask ijabz_
19:49:00 [nikki]
'cause it seems more like a search than a lookup
19:49:12 [ocharles]
that's a good observation :)
19:49:26 [ocharles]
I like the sound of handing that over to search server first
19:49:27 [ruaok]
move it to SEARCH and see what ijabz_ thinks
19:49:29 [reosarevok]
Ok
19:49:36 [reosarevok]
Do that then
19:49:37 [reosarevok]
[MBS-3385] When choosing a similar release (from "Release duplicates" tab), copied medium type should be set to unknown467
19:49:40 [reosarevok]
*please*
19:49:49 [ocharles]
easy, i'm fine with 3
19:49:52 [nikki]
* nikki likes the current behaviour :/
19:49:55 [ocharles]
but...
19:49:58 [ocharles]
that's not what the votes say :)
19:50:00 [reosarevok]
nikki: why?
19:50:11 [nikki]
because I already have to re-enter way too much info already
19:50:13 [reosarevok]
It is a real pain when adding vinyl + CD + digital
19:50:25 [nikki]
* nikki wants to just duplicate a release, change the catno/barcode and submit
19:50:40 [reosarevok]
That's a different ticket :p
19:50:51 [hawke_1]
It depends on what you’re doing, really.
19:50:51 [reosarevok]
(if there's none, add one)
19:50:54 [nikki]
but I can't do that, so reusing an existing tracklist is the closest I can get :P
19:51:11 [reosarevok]
Meh
19:51:25 [reosarevok]
It makes it fairly easy to enter wrong info by mistake
19:51:25 [ocharles]
12 it as an average, and discuss it
19:51:36 [hawke_1]
+1
19:51:39 [reosarevok]
vs. it makes it a bit harder to enter more accurate info
19:51:49 [reosarevok]
* reosarevok still thinks it should be changed
19:51:50 [reosarevok]
:p
19:51:55 [ocharles]
then say so
19:51:57 [nikki]
aha, I do have a ticket - http://tickets.musicbrainz.org/browse/MBS-3642
19:52:12 [reosarevok]
See? Implement this and the other :p
19:52:15 [reosarevok]
Ok
19:52:15 [reosarevok]
[MBS-2889] Advanced tracklist edit: artist field is disabled by default for multi-disc VA releases646
19:52:41 [reosarevok]
"Given that the field is automatically checked and editable straight away for VA releases with few discs (e.g. 2 disc releases) this is inconsistent, and makes for a frustrating user experience.
19:52:41 [reosarevok]
"
19:52:52 [reosarevok]
* reosarevok guesses a good amount of people agree?
19:52:55 [reosarevok]
Should be simple
19:53:04 [ruaok]
has no votes.
19:53:09 [reosarevok]
And I can't see no reason to *not* do it
19:53:13 [ocharles]
3 or 12 is fine
19:53:17 [ruaok]
k
19:53:20 [reosarevok]
ruaok: it has 6 3 mo and 4 12 mo
19:53:36 [ruaok]
I meant in jira, sorry.
19:53:40 [ocharles]
yea
19:53:40 [reosarevok]
I know
19:53:52 [reosarevok]
Which are much more meaningful because people will only see a jira ticket usually if linked on forums / IRC
19:54:12 [reosarevok]
So voting there is a lot of "who shouts louder"
19:54:13 [ocharles]
hum hum hum
19:54:25 [ruaok]
reosarevok: isn't that always the case? :)
19:54:37 [reosarevok]
ruaok, not if the tickets you see are random
19:54:40 [reosarevok]
See: ocharles' game
19:54:40 [reosarevok]
:p
19:54:46 [ocharles]
:)
19:54:47 [reosarevok]
So
19:54:51 [reosarevok]
12? 3?
19:54:53 [ocharles]
I can't decide
19:54:55 [reosarevok]
If it's easy, 3
19:54:59 [ruaok]
the act of going to ocharles' site is shouting. :)
19:55:00 [reosarevok]
If a bit less easy, 12
19:55:01 [ocharles]
nothing is ever easy in re land
19:55:18 [ocharles]
go 12 for now
19:55:20 [reosarevok]
12 + major?
19:55:20 [reosarevok]
:p
19:55:27 [ocharles]
nah, i don't see it as that major
19:55:31 [reosarevok]
Ok
19:55:31 [ruaok]
12
19:55:32 [reosarevok]
[MBS-2317] Recordings suggestions displays incorrect titles for suggested recording444
19:55:57 [reosarevok]
"Was this a one-off caching issue, or is it still a problem?
19:55:57 [reosarevok]
" wasn't answered
19:55:59 [reosarevok]
murdos?
19:56:15 [ocharles]
created all the way back in may, and no dupes since
19:56:42 [reosarevok]
Yeah
19:56:47 [reosarevok]
unsched and ask again
19:56:49 [ocharles]
unsched
19:56:50 [ocharles]
yea
19:56:53 [ruaok]
discuss!
19:57:12 [reosarevok]
[MBS-2716] Add a cluster "remove AR" feature168
19:57:16 [reosarevok]
RE editor? :p
19:57:20 [reosarevok]
*rel editor
19:57:27 [ocharles]
yea, but the 3 rel editor is 12 months
19:57:30 [ocharles]
(the work stuff is 3 months)
19:57:51 [ocharles]
I'd be ok with 12 there
19:58:04 [reosarevok]
Sure
19:58:06 [ruaok]
k
19:58:10 [reosarevok]
I'd even be OK with unsched
19:58:14 [reosarevok]
It doesn't seem that big an issue
19:58:27 [ocharles]
ok, unsched
19:58:27 [ocharles]
:P
19:58:36 [ocharles]
* ocharles is conscious that bucket is filling up
19:58:46 [reosarevok]
Fine
19:58:47 [reosarevok]
[MBS-2034] Release editor help/description bubbles break with a resizeable textarea358
19:58:54 [nikki]
unsched is filling up?
19:58:59 [ocharles]
nikki: no, 12mo
19:59:02 [nikki]
ah
19:59:05 [nikki]
was gonna say
19:59:10 [ocharles]
well, unsched is too
19:59:13 [ocharles]
they are about equal
19:59:27 [nikki]
well we can take stuff from unsched once the rest is done
19:59:30 [hawke_1]
Ooh, this is my ticket. :-)
19:59:30 [reosarevok]
Well, unsched should fill up :p
19:59:40 [nikki]
so it doesn't matter if unsched is getting "full"
19:59:42 [reosarevok]
* reosarevok doesn't really use those bubbles - so no idea
19:59:51 [reosarevok]
Probably 12 as it is RE
19:59:52 [ocharles]
nikki: I know, I never said it was. but 12 being too full is a problem
19:59:55 [reosarevok]
But no idea
20:00:05 [nikki]
ocharles: that's why I was asking, I thought you meant unsched
20:00:10 [ruaok]
do we keep adding to 12 and then do a triage on 12?
20:00:22 [ruaok]
re-eval what ought to be in unsched?
20:00:47 [ocharles]
ruaok: http://ocharles.org.uk/jira.html :)
20:00:49 [reosarevok]
Well, in theory we're commiting to it by moving it into 12
20:01:04 [ocharles]
hum, doesn't say. but the idea is they go from 12 to 3
20:01:16 [ocharles]
"Tickets should flow through buckets sequentially."
20:01:37 [reosarevok]
Let's stop here for now?
20:01:43 [reosarevok]
Someone decide where [MBS-2034] Release editor help/description bubbles break with a resizeable textarea358 should go
20:01:46 [ocharles]
so when 3 months is empty, we need to pick new things from the 12 month bucket. but in reality, we're taking stuff that's not scheduled at all and putting it in 3 months
20:01:50 [ocharles]
reosarevok: +1
20:01:58 [ocharles]
and i'd say unsched
20:02:18 [hawke_1]
agreed.
20:02:22 [nikki]
food time for me anyway
20:02:22 [hawke_1]
It’s a pretty minor problem
20:02:27 [hawke_1]
even for those it affects
20:04:47 [ocharles]
740 issues to go :P
20:05:27 [ruaok]
ocharles: got minute to discuss http://codereview.musicbrainz.org/r/1697/# ?
20:05:41 [ocharles]
aye
20:05:56 [ruaok]
when do we show coverart from the archive on a release page?
20:06:01 [ruaok]
how is that process determined?
20:06:16 [ocharles]
we query the coverartarchive web service
20:06:44 [ruaok]
regardeless if we know something exists in the archive or not?
20:06:49 [ocharles]
yes
20:06:59 [ruaok]
that seems wasteful.
20:07:10 [ocharles]
the caa is fast, it shouldn't be much more than a lookup
20:07:13 [ocharles]
the server is on our network
20:07:24 [ocharles]
gotta query a service somewhere, might as well centralise it
20:07:28 [ruaok]
but if we can avoid making that call, lets.
20:07:43 [ruaok]
why not use the flag in release_meta to determine that we have coverart in CAA?
20:07:56 [ruaok]
that way someone who downloads the data can inspect it.
20:08:06 [ruaok]
rather than having to check each release in MB.
20:08:26 [ocharles]
that is a nice feature you get, but otherwise it seems like a premature optimismation to me
20:08:33 [ocharles]
optimisation*
20:08:40 [ruaok]
I disagree.
20:08:49 [ruaok]
its an important feature from the perspective of a data user.
20:08:58 [ruaok]
because without that flag I can't tell what is in the CAA.
20:08:59 [ocharles]
yea, I agree that feature is nice
20:09:02 [ocharles]
i'm not against that
20:09:07 [ruaok]
and that makes the CAA much less useful.
20:09:09 [ocharles]
just making sure it provides features that the CAA doesn't
20:09:23 [ruaok]
then r1697 should make that happen.
20:09:23 [ocharles]
on the otherhand, why can't I get a dump of all mbids with cover art from the cover art archive?
20:09:38 [ocharles]
maybe i'm working one a app that just mashes images up, so I don't want to do a full database dump
20:09:38 [ruaok]
is that possible now?
20:09:50 [ruaok]
or does that require the archive to do more work?
20:10:05 [ruaok]
for some users that will work, yes.
20:10:06 [ocharles]
it would be us, it's just which application does the work
20:10:18 [ocharles]
someone has to do more work - either musicbrainz-server tracks this, or caa.org does
20:10:35 [ruaok]
its not much work for us to track this. so we should do it.
20:10:48 [ocharles]
ok, but it's not boolean then by the sounds of things
20:10:57 [ruaok]
and getting the IA do to anything has proven hard.
20:11:01 [ruaok]
agreed.
20:11:05 [ruaok]
its a tri-state at least.
20:11:07 [ocharles]
it's 3 enumerations -- no artwork, has artwork, cannot have artwork
20:11:12 [ruaok]
have none, have, darkenred.
20:11:14 [ocharles]
ok, i can change it to that
20:11:14 [ruaok]
+1
20:11:20 [nikki]
will our ws be returning that a release has cover art in the caa?
20:11:23 [ruaok]
ok, please do.
20:11:28 [ocharles]
nikki: with this, it can
20:11:32 [ruaok]
and then create the code to keep that field updated.
20:11:46 [nikki]
* nikki is for that then
20:11:55 [ocharles]
* ocharles discards his review
20:12:02 [ruaok]
and then please lets not emit links to the CAA if that flag says no art or darkened.
20:12:15 [ruaok]
ocharles: thanks.
20:12:26 [nikki]
it seems silly to make everyone query the caa too to find out when we know if there's some or not because we put it there
20:12:34 [ruaok]
* ruaok nods at nikki
20:13:05 [ocharles]
could know*
20:13:07 [ocharles]
we don't know atm :)
20:14:03 [nikki]
should know :P
20:55:43 [ruaok]
ocharles: I'll be in london during the week of Jan 23.
20:55:58 [ruaok]
I'll also be taking up a desk at last.fm while I am not running around london.
20:56:11 [ruaok]
reosarevok: ping
20:56:17 [reosarevok]
pong
20:56:35 [ruaok]
I'm leaning towards Jan 30 for the mini-summit.
20:56:49 [hawke_1]
* hawke_1 murders “Song-Cycle”
20:56:52 [ruaok]
I may ask ocharles to join us as well.
20:57:03 [reosarevok]
Hmmm, while the previous Fri might be nicer, I guess 30 works too
20:57:29 [ruaok]
fri would be my second choice, for sure.
20:57:41 [ruaok]
we'll have to see what the BBC says about meeting space.
20:58:05 [reosarevok]
It will mean I have to stay a couple weeks at my family's place in Spain before my exams, but given that I haven't done so for 6 mo it might be a good thing
20:58:10 [reosarevok]
Show I am not dead, all that
20:58:19 [nikki]
hah
20:58:19 [reosarevok]
Maybe even study a bit
21:00:01 [reosarevok]
and flying to Spain in the weekend might be too expensive anyway
21:42:47 [ijabz_]
ruaok: I have updated the error message for 503's in the rate limiter stuff if you want to update the server
21:43:01 [ruaok]
not really, TBH.
21:43:10 [ruaok]
lets wait for something more substantial.
21:49:36 [ijabz_]
Yeah, it was effort for me to make the code change, but i did promise dave
21:50:19 [ruaok]
understood. blame it on me for not getting it out. :)
21:50:31 [ruaok]
we'll have other reasons to update the search soon. :)
21:50:35 [ruaok]
(for whatever reason)
21:51:37 [ijabz_]
I was reviewing some new issues raised today, trouble is keeps distracting me from my planned work, but muffin new there
21:52:19 [ruaok]
I hear ya. :)
22:17:04 [kepstin]
kepstin has joined #musicbrainz-devel
22:29:18 [ijabz]
ijabz has joined #musicbrainz-devel
22:35:29 [kepstin]
kepstin has joined #musicbrainz-devel
22:47:25 [bitmap]
luks: your mbs-4104 patch is affecting all recordings on the releases, I thought it would only affect recordings that would be merged :)
22:48:39 [bitmap]
e.g. I tried merging a 1-disc release into a 3-disc release and the edit shows up in recordings/artists for discs 2 & 3 on the target release
22:49:13 [luks]
oh, that is possible?
22:49:20 [bitmap]
yeah
22:50:27 [luks]
I'm working on 4105 now, creating the list of recordings that are going to be merged is far from easy
22:50:43 [bitmap]
ah :/
22:50:53 [luks]
I'll use the same code for 4104 when it's done
22:55:49 [alastairp]
alastairp has joined #musicbrainz-devel
22:56:02 [reosarevok]
heh
22:56:04 [reosarevok]
"MusicBrainz devs have said explicitly that they despise the categorization of music into genres, so I doubt it will ever happen.
22:56:04 [reosarevok]
"
22:56:07 [reosarevok]
(from 2005)
22:56:54 [luks]
is it going to happen?
22:57:32 [reosarevok]
* reosarevok has no idea
22:57:52 [reosarevok]
I just find it funny that the devs "explicitly said" that
22:58:13 [reosarevok]
And 5 years later, in the summit, the devs said "genre wouldn't be that bad" :p
22:58:24 [reosarevok]
(admittedly, different devs mostly!)
23:01:31 [nikki]
reosarevok: just like I find it hilarious that we claim we don't want to store them because they're subjective, yet we enter them in artist comments anyway
23:02:24 [reosarevok]
Well, some people would say artist comments can be more subjective than the factual data as long as they help identify stuff
23:02:45 [reosarevok]
But still, yeah :p
23:02:50 [nikki]
but comments are still something that have to be voted on normally
23:03:07 [nikki]
so people can be like "nuh uh, this is so not rock, it's METAL, are you stupid or something" :P
23:03:21 [nikki]
but if that's been happening, I haven't seen it
23:05:59 [Leftmost]
Leftmost has joined #musicbrainz-devel
23:07:09 [murdos]
murdos has joined #musicbrainz-devel
23:13:23 [Leftmost]
Leftmost has joined #musicbrainz-devel
23:13:23 [Leftmost]
Leftmost has joined #musicbrainz-devel
23:14:03 [luks]
nikki: any suggestion for the release merge warning text?
23:14:04 [luks]
http://dl.dropbox.com/u/5215054/tmp/badmerge.png
23:15:37 [reosarevok]
Warning: The recordings being merged have different (titles? artists? what does it check?). Are you sure this is correct?
23:16:10 [luks]
artists
23:17:28 [reosarevok]
If you choose to still merge, it will allow it, right?
23:18:02 [nikki]
"Warning: BAD MERGE" XD
23:18:08 [nikki]
I like that, pity it's not user friendly enough
23:18:32 [bitmap]
haha
23:18:40 [reosarevok]
Yeah
23:18:50 [reosarevok]
"Warning: WTF DUDE NO!"
23:19:34 [reosarevok]
Warning: This will cause recordings with different artists to be merged. Are you sure?
23:19:41 [reosarevok]
Something like that I guess
23:20:04 [luks]
reosarevok: yes, it will allow you to merge
23:20:38 [reosarevok]
If they say, yes, load it again, but with "Are you really, really sure?"
23:20:39 [reosarevok]
:p
23:20:59 [nikki]
"Warning: The releases being merged have different track artists and will cause recordings with different artists to be merged. Perhaps you meant to use the "append mediums" strategy."?
23:21:05 [nikki]
or something
23:21:44 [luks]
it actually checks recording artists, not track artists
23:22:08 [nikki]
ah
23:22:40 [luks]
I guess merging tracks with different credits is ok as long as the recording artists are the same
23:23:05 [luks]
I could also check the recording durations
23:23:43 [bitmap]
that'd be nice, too
23:24:55 [bitmap]
regular recording merges don't check the durations either, or do they?
23:25:59 [reosarevok]
They show it in the edit
23:26:14 [reosarevok]
I don't think they make a check and discourage you, nope
23:26:22 [nikki]
hmm... or maybe "Warning: The recording artists do not match! Perhaps you meant to use the "append mediums" merge strategy?" with "If you continue with the current merge strategy, the following recordings will be merged:" underneath?
23:27:33 [bitmap]
* bitmap likes that suggestion
23:28:20 [luks]
thanks, that looks good
23:28:21 [luks]
http://dl.dropbox.com/u/5215054/tmp/badmerge2.png
23:28:31 [luks]
oops
23:29:47 [reosarevok]
Are you going to show the recording list always?
23:29:51 [reosarevok]
Or just when they don't match?
23:30:14 [luks]
it only lists recordings that don't match
23:30:40 [reosarevok]
Hmm
23:30:43 [luks]
should I list all merges?
23:30:45 [reosarevok]
I wouldn't mind it listing all
23:30:51 [reosarevok]
But it might be too much?
23:30:52 [reosarevok]
Dunno
23:31:00 [reosarevok]
What do people think? :)
23:31:13 [nikki]
if you list them all, I would list the non-matching ones first
23:32:05 [nikki]
or perhaps with some sort of styling to make them stand out more than the ones where the artists do match
23:32:20 [reosarevok]
I say it more because it is not *only* a problem when the artists do not match
23:32:28 [bitmap]
maybe for matching ones it'd be useful to show disambiguation comments, in case they're different versions
23:32:40 [reosarevok]
I mean, the chance of choosing "merge" instead of "append" exists also with a single artist
23:32:40 [nikki]
it should show them anyway
23:33:04 [reosarevok]
(I guess that's why I'd like the check to be a bit more than just artist)
23:33:11 [luks]
reosarevok: which is why I wanted to add the duration check
23:33:20 [reosarevok]
Oh, I see now :)
23:33:38 [luks]
with 10 or so max duration difference
23:33:39 [reosarevok]
If you add that too, I'm fine with showing only the ones that seem wrong
23:33:52 [reosarevok]
Should stop most of the problems
23:34:15 [reosarevok]
Leaves the case of the ones with no duration set, I guess
23:34:20 [reosarevok]
But hey, you can't have it all
23:34:48 [luks]
well, I'm going to do only artists in the first step
23:34:56 [luks]
durations will be done later
23:34:57 [nikki]
* nikki thinks it'd be fine to show all the merges
23:36:19 [reosarevok]
Hmm
23:36:30 [bitmap]
I agree, it makes the consequences of the edit more apparent to new users
23:37:17 [reosarevok]
Yeah
23:37:29 [reosarevok]
If someone makes a 10 disc merge, bad luck
23:37:40 [reosarevok]
Won't be too common anyway
23:38:18 [reosarevok]
* reosarevok wtfs http://i.imgur.com/Ry3x9.jpg
23:38:38 [reosarevok]
I mean, I see what the issue is
23:38:45 [reosarevok]
But why is it serving me code?
23:40:40 [Leftmost]
Leftmost has joined #musicbrainz-devel
23:58:42 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel