IRC log of musicbrainz-devel on 2013-01-21

Timestamps are in UTC.

00:00:16 [Freso]
Anyone who can help me debug why I can't connect to rika via mosh?
00:00:25 [Freso]
s/can/wants to/
00:01:39 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
00:10:51 [nikki]
what about if we want to but can't? :P
00:10:59 [nikki]
* nikki has no idea what mosh even is, let alone how to debug it :P
00:12:13 [Freso]
nikki: http://mosh.mit.edu/ :) And I'm guessing the question is mostly directed towards ianmcorvidae or warp :)
00:13:06 [nikki]
ianmcorvidae is out, afaik, and warp should be in bed
00:15:07 [Freso]
This is brill: http://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-prn1/75308_10151135476831184_1251686327_n.jpg
00:18:51 [reosarevok]
Ugh is that sand'
00:19:09 [reosarevok]
Why would anyone willingly put sand at home, it's annoying enough at the beach :)
00:19:45 [nikki]
D:
00:20:53 [reosarevok]
Now if it was grass...
00:22:15 [nikki]
also not nice
00:22:37 [Freso]
If it was GLOWING EMBERS!
00:23:47 [nikki]
no
00:23:49 [reosarevok]
SPIKES!
00:23:53 [nikki]
no
00:23:56 [Freso]
SPIKES! D:
00:24:04 [Freso]
nikki: Rose petals?
00:24:07 [nikki]
no
00:24:12 [Freso]
fluffy bunnies?
00:24:14 [nikki]
no
00:24:17 [Freso]
(Dead fluffy bunnies?)
00:24:20 [nikki]
no
00:24:23 [Freso]
Aw.
00:24:32 [Freso]
reosarevok: Why's miss n so negative tonight? D:
00:24:44 [nikki]
too many electrons
00:25:32 [reosarevok]
A magical bridge of hope and wonder!
00:30:03 [nikki]
if I were going for fancy flooring, it'd be marble, tiles or parquet. but tbh I don't have anything against this wooden stuff we've got now.
00:30:57 [Freso]
I would But it wasn't for all of the floor. Just the bit around your magical work place with the computer.
00:31:12 [nikki]
yes
00:31:26 [nikki]
I like the wheels on my chair to actually move
00:31:39 [nikki]
so sand and grass and dead fluffy bunnies are all horrible
00:34:14 [Ben\Sput]
Ben\Sput has joined #musicbrainz-devel
00:47:42 [Ben\Sput]
Ben\Sput has left #musicbrainz-devel
00:58:11 [kepstin]
kepstin has joined #musicbrainz-devel
01:01:12 [kepstin]
hmm. the redirector on coverartarchive.org isn't really all that fast :/
01:01:57 [ianmcorvidae]
oh?
01:02:20 [kepstin]
most requests seem to be taking 150-200ms, but I see odd ones now and then which take 600-800ms
01:02:29 [ianmcorvidae]
ah, yeah, that's not terribly fast
01:02:53 [ianmcorvidae]
I wonder what all it's doing
01:02:58 [ianmcorvidae]
this is for /front, I guess?
01:03:11 [kepstin]
meanwhile, the archive.org/download redirector consistently is in the ~100ms range
01:03:19 [kepstin]
yeah, for release group front images
01:04:49 [kepstin]
oh, no wonder, I'm using /beta
01:04:56 [kepstin]
* kepstin switches that back to non-beta
01:05:07 [ianmcorvidae]
oh, heh
01:05:12 [nikki]
why would that affect it?
01:05:23 [ianmcorvidae]
I think the beta redirector might be on hobbes
01:05:58 [ianmcorvidae]
hm, no, never mind
01:06:00 [ianmcorvidae]
both pino
01:06:22 [kepstin]
hmm. didn't really make any difference, yeah
01:06:49 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
01:06:53 [ianmcorvidae]
hm
01:07:02 [ianmcorvidae]
example MBID? I'm curious how long the SQL query is taking
01:07:19 [kepstin]
http://coverartarchive.org/release-group/27d2fe3a-9f86-4faa-b0b2-fe5cff5b9287/front-250 is one of the urls i'm using
01:07:41 [kepstin]
http://mbjs.kepstin.ca/?artist=1a83b2c2-a848-496a-8220-3f22d0fb47db is the page that i'm seeing this on; this is trying to load a whole bunch of images quickly.
01:08:29 [ianmcorvidae]
hm
01:08:30 [kepstin]
the archive.org side of it isn't superfast either, so the images take their time to load.
01:08:34 [ianmcorvidae]
0.219ms
01:08:40 [ianmcorvidae]
for the query
01:08:51 [kepstin]
the issue is that the browser's not caching the 307 on coverartarchive.org or the 302 on archive.org/download
01:08:55 [nikki]
I wonder why archive.org only sometimes redirects
01:09:00 [kepstin]
so it has to re-do those requests every time
01:09:09 [demosdemon]
demosdemon has joined #musicbrainz-devel
01:09:32 [kepstin]
this wouldn't annoy me so much if the browser could cache the redirects.
01:09:42 [Freso]
ianmcorvidae: If you have time and want to, could you help me debug my connection to/with mosh on rika?
01:10:12 [kepstin]
because now I have to wait almost a second after page load for the browser to talk to all the servers to realize "hey, this image is actually the same as the cached one" and display it.
01:11:01 [ianmcorvidae]
Freso: you won't get one, that requires UDP?
01:11:13 [ianmcorvidae]
and I don't think mosh has implemented any UDP holepunching stuff, so
01:11:20 [reosarevok]
reosarevok has joined #musicbrainz-devel
01:11:34 [kepstin]
mosh requires incoming udp connections on ports 60000-61000 by default on the remote server, yeah
01:11:36 [Freso]
ianmcorvidae: Alright. So it's installed, but completely unusable? Awesome. :D
01:11:44 [ianmcorvidae]
sounds right :P
01:12:05 [ianmcorvidae]
and yeah, I'm not sure what's taking caa.org so long
01:12:05 [Freso]
Oh well.
01:12:11 [ianmcorvidae]
the query takes 0.2s, so I guess it's in python
01:12:21 [Freso]
But thanks for helping me debug it anyway. ;)
01:12:40 [kepstin]
browsers do support caching 307s, I wonder if it would make sense to put some caching headers on coverartarchive.org
01:16:10 [kepstin]
I suppose putting caching on the redirector would make editing cover art more annoying than it already is :/
01:17:17 [nikki]
at least for /front, yeah
01:17:57 [nikki]
things like /release/mbid/id.jpg should be cachacle
01:18:21 [kepstin]
actually, musicbrainz.org doesn't every use the /front aliases
01:19:41 [kepstin]
since musicbrainz.org already knows which image is the front image, it links to it directly.
01:20:20 [kepstin]
so only external stuff uses /front, and possibly having an older /front image following an edit for external stuff probably isn't as bad. hmm.
01:20:34 [ianmcorvidae]
mb.org may use /front
01:20:40 [ianmcorvidae]
I wouldn't be surprised :P
01:20:54 [kepstin]
ianmcorvidae: I just looked at the html of the generated pages on musicbrainz.org
01:20:56 [ianmcorvidae]
it means you don't need to do a database query for the release
01:20:57 [ianmcorvidae]
ah, okay
01:20:58 [kepstin]
they don't use /front :)
01:21:40 [kepstin]
maybe I should run the caa redirector through an nginx proxy on mbjs.kepstin.ca and add some caching headers to it on the way through :/
01:22:10 [kepstin]
(doesn't help the archive.org/download redirector not being cached either, but it removes one step, anyways)
01:25:59 [kepstin]
(as a reminder, if you use firefox, go to about:config and set "image.high_quality_downscaling.enabled" to true to make cover art images look better ;)
01:27:07 [Freso]
kepstin: I thought I'd forgot to do that. Turns out I didn't forget. :)
01:28:22 [kepstin]
I have no idea why that's not on by default
01:28:32 [kepstin]
it's just a "make things work better" option :/
01:28:40 [kepstin]
it shouldn't be optional.
01:44:26 [misterswag]
misterswag has joined #musicbrainz-devel
01:56:27 [nikki]
hm. the redirect or not stuff definitely seems totally random
01:57:34 [nikki]
the image in http://archive.org/details/CygnusExpress gives me a redirect, the one in http://archive.org/details/Claddagh doesn't
01:58:45 [nikki]
both thumbnails redirect though... o_O
02:31:46 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
02:55:36 [Prophet5]
Prophet5 has joined #musicbrainz-devel
03:27:02 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
03:54:28 [Leftmost]
Leftmost has joined #musicbrainz-devel
03:54:28 [Leftmost]
Leftmost has joined #musicbrainz-devel
04:22:27 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
04:48:52 [Prophet5_]
Prophet5_ has joined #musicbrainz-devel
05:14:30 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
06:09:45 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
06:53:06 [Leftmost]
Leftmost has joined #musicbrainz-devel
07:08:11 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
08:43:17 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
09:00:01 [MBJenkins]
Project musicbrainz-server_beta build #293: FAILURE in 29 min: http://ci.musicbrainz.org/job/musicbrainz-server_beta/293/
09:00:02 [MBJenkins]
* ianmcorvidae: MBS-5044: don't use absolute paths for favicon images
09:00:02 [MBJenkins]
* ianmcorvidae: MBS-5044: migrate inline & non-background style images:
09:00:03 [MBJenkins]
* ianmcorvidae: MBS-5614: Link edit notes (and annotation wikidocs links) correctly depending on https/non-https state
09:00:03 [MBJenkins]
* ianmcorvidae: MBS-5614-aux: link entities to correct ssl/non-ssl in annotations
09:00:04 [MBJenkins]
* ianmcorvidae: optimize .png files
09:00:04 [MBJenkins]
* ianmcorvidae: MBS-5044: collapse forms.css declarations somewhat
09:00:05 [MBJenkins]
* ianmcorvidae: MBS-5044: remove remaining <img> uses of add_row/delete_row
09:00:05 [MBJenkins]
* ianmcorvidae: MBS-5044: remove tablesort.css, which is unused
09:00:05 [MBJenkins]
* ianmcorvidae: style: wrap new forms.css declarations at 80 characters
09:00:06 [MBJenkins]
* ianmcorvidae: MBS-5044: losslessly optimize ui-bg_gloss-wave_35_f6a828_500x100.png
09:00:07 [MBJenkins]
* ianmcorvidae: reoptimize changed add_row.png
09:00:07 [MBJenkins]
* ianmcorvidae: MBS-5614: Use a new _make_link function to produce entity links conditionally
09:00:08 [MBJenkins]
* ianmcorvidae: MBS-5614: update and document tests
09:00:08 [MBJenkins]
* ianmcorvidae: MBS-5614-ext: only the first MBID link was getting expanded, and switch to relative links
09:00:09 [ianmcorvidae]
bah, seriously
09:00:10 [MBJenkins]
* reosarevok: Allowing us to use permanent citation URLs from Trove
09:09:05 [demosdemon]
demosdemon has joined #musicbrainz-devel
09:16:47 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
09:31:38 [Ben\Sput]
Ben\Sput has joined #musicbrainz-devel
09:34:10 [MBJenkins]
Yippie, build fixed!
09:34:10 [MBJenkins]
Project musicbrainz-server_beta build #294: FIXED in 28 min: http://ci.musicbrainz.org/job/musicbrainz-server_beta/294/
09:34:11 [MBJenkins]
ianmcorvidae: Remove erroneous @href from button element
09:35:40 [zas]
zas has joined #musicbrainz-devel
09:36:28 [sivoais_]
sivoais_ has joined #musicbrainz-devel
09:36:44 [Leftmost]
Leftmost has joined #musicbrainz-devel
09:36:44 [Leftmost]
Leftmost has joined #musicbrainz-devel
09:43:43 [Leftmost]
Leftmost has joined #musicbrainz-devel
09:43:43 [Leftmost]
Leftmost has joined #musicbrainz-devel
09:48:03 [demosdemon]
demosdemon has joined #musicbrainz-devel
09:51:42 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
10:14:46 [Ben\Sput]
Ben\Sput has left #musicbrainz-devel
10:26:30 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
10:58:47 [warp]
Freso: how do you normally connect with rika (with ssh)
10:58:48 [warp]
?
11:19:41 [djce]
djce has joined #musicbrainz-devel
11:35:10 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
11:37:30 [zas]
archive.org still hosed....
11:38:02 [nikki]
still nothing we can do about it
11:38:14 [zas]
very annoying for users
11:38:24 [nikki]
I totally agree
11:38:31 [zas]
and Hi, Nikki ;)
11:38:46 [Ben\Sput]
Ben\Sput has joined #musicbrainz-devel
11:38:49 [nikki]
hi
11:38:50 [zas]
it happens (too) often
11:41:39 [zas]
is it due to server overload ? or any official explanation ?
11:45:22 [nikki]
it's usually a problem of some sort with a server. I don't know the exact details of what's wrong today
11:47:57 [zas]
bitmap, luks: ping ?
11:49:12 [zas]
i'm thinking about cover art handling in Picard, mostly about using existing cover.jpg
11:49:50 [zas]
when a release has no cover art at all on MB/CAA, but a cover.jpg exists in local directory, Picard could use it
11:55:40 [MBJenkins]
Project musicbrainz-server_beta build #295: FAILURE in 29 min: http://ci.musicbrainz.org/job/musicbrainz-server_beta/295/
11:55:41 [MBJenkins]
* warp: MBS-5609, enable release relationships and include relationship dates in /ws/2 json webservice.
11:55:41 [MBJenkins]
* warp: MBS-5609, move serializing of a group of begind/end partialdates to a seperate function.
11:55:42 [MBJenkins]
* warp: MBS-5609, rename the inaccurate WebService::Serializer::JSON::2::Utils::partialdate to dateperiod.
11:55:42 [MBJenkins]
* warp: MBS-5586, do not call "post_creation" if no edit was created.
11:55:43 [MBJenkins]
* warp: MBS-5586, clarify use of the post_creation and on_creation hooks.
11:55:43 [MBJenkins]
* warp: MBS-5609, remove some bitrot from script/release-group-sql-dump.pl and use it to add an l_artist_artist link in t/sql/webservice.sql.
11:55:44 [MBJenkins]
* warp: MBS-5609, rename dateperiod to date_period.
11:55:44 [MBJenkins]
* warp: MBS-5609, add artist "member of band" artist relationship in webservice tests (this tests a begin date).
11:55:45 [MBJenkins]
* warp: MBS-5712, always include alias locale and primary flag.
11:55:45 [MBJenkins]
* warp: MBS-5711, do not include IPIs in json webservice unless they're on a toplevel entity.
11:55:46 [MBJenkins]
* warp: MBS-5712, semi-colon missing from previous commit.
11:55:46 [MBJenkins]
* warp: MBS-5713, include alias type in JSON webservice.
11:55:47 [MBJenkins]
* warp: MBS-5713, include alias type in json webservice.
11:55:47 [MBJenkins]
* warp: MBS-5586, both post_creation and on_creation hooks should be called from within the transaction.
11:55:48 [MBJenkins]
* warp: MBS-5609, add a release relationship in the webservice tests.
11:55:48 [MBJenkins]
* warp: MBS-5586, do not change the order of post_creation and on_creation hooks.
11:55:49 [MBJenkins]
* warp: Fix bad merge of MBS-5609 + MBS-5711.
12:01:27 [nikki_]
nikki_ has joined #musicbrainz-devel
12:03:06 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: reviews, translation sorting stuff (catcat), MBS-5757 (reotab), github pull vs codereview (warp), CAA-39 (warp), nes & transactions (ocharles), schema change release (warp)
12:10:25 [ijabz]
ijabz has joined #musicbrainz-devel
12:10:56 [Freso]
Freso has joined #musicbrainz-devel
12:21:36 [kepstin-work]
kepstin-work has joined #musicbrainz-devel
12:24:50 [MBJenkins]
Project musicbrainz-server_beta build #296: STILL FAILING in 29 min: http://ci.musicbrainz.org/job/musicbrainz-server_beta/296/
12:24:50 [MBJenkins]
pavan: MBS-5758: Remove swag link
12:51:57 [Freso]
warp: What do you mean?
12:52:03 [Freso]
(connecting to rika)
12:52:06 [Freso]
`ssh rika`
12:52:36 [Freso]
(With "rika" being an alias for z-something.mb.o in the .ssh/config.)
12:54:00 [MBJenkins]
Project musicbrainz-server_beta build #297: STILL FAILING in 29 min: http://ci.musicbrainz.org/job/musicbrainz-server_beta/297/
12:54:01 [MBJenkins]
warp: When serializing releases in the json webservice: do not try to load coverart from the stash if there is no stash.
12:57:13 [reosarevok]
reosarevok has joined #musicbrainz-devel
13:14:15 [luks]
zas: pong
13:15:28 [luks]
also, sorry, but as you have found out, picard really doesn't have an active maintainer
13:15:51 [luks]
so working more actively on picard more or less means that you will have to become the maintainer :)
13:16:09 [luks]
and for decisions like this, it's best to ask people on forums.musicbrainz.org
13:18:03 [mat_]
hum, is there a ticket somewhere about a way of having track relationships in picard for big releases ?
13:26:46 [nikki]
how would it do that?
13:26:59 [nikki]
the problem is that the server times out when trying to return the info
13:33:07 [zas]
luks: yup noticed the lack of active maintainer ;)
13:33:46 [nikki]
mat_: http://tickets.musicbrainz.org/browse/MBS-3680 http://tickets.musicbrainz.org/browse/MBS-3841
13:33:56 [nikki]
(for the server)
13:35:43 [luks]
zas: we've already lost a few possible contributors because of that
13:36:20 [luks]
so if you are expecting some active feedback, it's probably going to be disappointing
13:36:40 [luks]
I can review some of the code over weekend, but I'd rather not make decisions about any functionality
13:39:25 [zas]
luks: i could become a maintainer, but i feel i'm far too new to this stuff to handle the job as it should
13:40:53 [zas]
nikki, mat_: interesting, issues still exist ? seems it was more a webservice issue than a picard one
13:41:48 [mat_]
zas, well, yes, depending on the amount of information needed, the webservice takes too long
13:41:59 [nikki]
yes. nothing has been done yet about the problems loading data
13:50:40 [navap]
"and I always consider voice to be be the voice of the people" heh :)
14:06:08 [nikki]
nikki has joined #musicbrainz-devel
14:07:54 [luks]
zas: also, can you please not rebase your branches?
14:08:01 [luks]
it makes reviewing updates really hard
14:09:10 [misterswag]
misterswag has joined #musicbrainz-devel
14:25:16 [zas]
luks: oh sorry, in fact, i create PRs far too soon ;)
14:26:38 [luks]
that's fine, but commits with later fixes are really not bad
14:27:00 [luks]
from history point of view, you can see that there was something wrong
14:31:23 [zas]
MB webservice isn't responding atm for me
14:53:13 [ocharles]
* ocharles prefers a history where every commit at least compiles, or better passes tests
14:53:16 [ocharles]
can make bisection much easier
14:53:30 [ocharles]
so i'm in favour of rebasing to other 'whoops, missed a ;'
14:53:44 [ocharles]
but massive re-arrangements can make reviewing a nightmare, especially if you introduce abstractions that are used later
14:56:36 [luks]
I think if you make a repository public, I think it should not be rewritten
14:57:02 [luks]
because if you base some review comments on the old commits, they are lost with rebase
14:58:10 [luks]
otherwise you have to review everything from scratch
15:00:02 [reosarevok]
reosarevok has joined #musicbrainz-devel
15:00:58 [zas]
well, rebase should occur before merging to main project, to ease future bisections, but during review time it is prolly better to not rebase branches
15:01:11 [luks]
I don't agree with that either
15:03:27 [zas]
code has to be fully functionnal between each commit (if possible ofc), especially in master branch, else bisection can become a nightmare
15:04:00 [zas]
but during proposed changes stage i think it is quite hard to achieve, because code under review _will_ chnage
15:04:27 [zas]
luks: i change setup.py to handle that _translate() issue
15:06:57 [Ben\Sput]
Ben\Sput has joined #musicbrainz-devel
15:09:04 [luks]
code will never be fully functional between commits :)
15:09:16 [luks]
not even remotely close to that
15:13:09 [zas]
i disagree, but nvm ;)
15:13:13 [zas]
https://github.com/zas/picard/commit/b8e1cc6dd717b3be0502240841dce8746fd049aa
15:13:46 [zas]
is this setup change ok ? i'm using both regexps to handle all pyuic versions
15:15:24 [luks]
yes, that looks good
15:15:56 [luks]
actually, not it doesn't
15:16:15 [luks]
you should set source to tmp.getvalue() before the loop
15:16:26 [luks]
and then replace the strings in source
15:16:41 [luks]
this way will only apply the last regex
15:19:18 [ocharles]
luks: oh sure, you shouldn't ever rebase public work
15:19:22 [ocharles]
once it's pushed, that's history
15:23:24 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
15:28:19 [zas]
luks: check https://github.com/zas/picard/commits/setup_translate
15:28:25 [zas]
afk few mins
15:48:27 [luks]
zas: looks fine, merged
15:56:42 [ijabz]
ijabz has joined #musicbrainz-devel
16:06:12 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
16:14:26 [hawke_]
hawke_ has joined #musicbrainz-devel
16:15:51 [hawke]
hawke has joined #musicbrainz-devel
16:22:09 [Ben\Sput]
Ben\Sput has left #musicbrainz-devel
16:23:48 [sivoais]
sivoais has joined #musicbrainz-devel
16:27:13 [voiceinsideyou1]
voiceinsideyou1 has joined #musicbrainz-devel
16:30:42 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
17:01:21 [djce]
djce has joined #musicbrainz-devel
17:08:24 [ijabz]
luks: is there a mimiim length for an acoustid fingerprint, I just want to do some minimal verification before using a fingerprint in a query in-case got corrupted i some way (i.e user edited metadata)
17:13:30 [hawke_]
ijabz: something in the range of 10–14 seconds will not produce an acoustID. (I can’t remember the exact number)
17:13:38 [hawke_]
(that amount or less)
17:15:11 [ijabz]
hawk, thx but not war I mean. I mean if I already have a fingerprint (stored in a metadata) what is the minimumlength it can be to check it could actually be a fingerprint, i.e an acoustic id would always be 36 chars
17:17:16 [hawke_]
Ah. I’m surprised you wouldn’t just recalculate the fingerprint from the audio.
17:18:26 [ijabz]
takes time, i.e if I'm checking 10,000 files that have fingerprints i don't want to do all 10,000 fingerprints agan
17:18:46 [luks]
the shortest encoded fingerprint will be a few bytes long
17:19:03 [luks]
I think it's 6 or 7
17:19:32 [ijabz]
that short, gosh, okay thx
17:20:00 [luks]
"AQAAAA" is the empty fingerprint
17:20:15 [luks]
you could theoretically write a function to validate it
17:20:38 [luks]
after base64-decoding it, there is a header with the length and version
17:20:48 [zas]
acoustID aren't generated for files under 10s afair
17:20:56 [hawke_]
zas: No, but fingerprints are.
17:21:08 [zas]
yup
17:21:16 [luks]
the minimum length for a fingerprint is somewhere around 3 seconds
17:21:35 [luks]
anything shorted than that will generate AQAAAA, which means the fingerprint is empty
17:23:23 [hawke_]
That won’t return anything useful from the server though. :-D
17:25:22 [ijabz]
does fingerprint always start AQA ?
17:25:54 [voiceinsideyou]
voiceinsideyou has joined #musicbrainz-devel
17:27:01 [luks]
ijabz: no
17:27:40 [luks]
let me look up the format
17:29:37 [luks]
actually, I don't think you can validate it without completely decompressing it
17:30:18 [luks]
you could base64-decode it and the first byte should be 1
17:30:34 [luks]
the rest is meaningless without actually decompressing it
17:30:55 [luks]
(1 is the version of the fingerprint algorithm)
17:31:02 [ijabz]
ok, no problem , not really necessary
17:33:40 [Ben\Sput]
Ben\Sput has joined #musicbrainz-devel
17:33:47 [Ben\Sput]
so, i was looking at audio books
17:33:59 [Ben\Sput]
and there's a bug with releases where the total length is more than 1 day
17:34:00 [Ben\Sput]
http://musicbrainz.org/release/41301ebe-2aa6-42fc-a986-e041a77cc9aa
17:34:29 [zas]
luks: http://help.transifex.com/features/client/#defining-the-mode-of-the-translated-file
17:34:45 [Ben\Sput]
I expect the actual total track time should probably be 24:55:03
17:35:05 [luks]
zas: how would that help us?
17:35:10 [zas]
do i understand correctly tx --mode option allows to have a 'dev' version of translation ?
17:36:21 [djce]
djce has joined #musicbrainz-devel
17:36:50 [luks]
to be honest, we don't have resources to maintain multiple version of translations in transifex
17:37:30 [zas]
well, dev version is only the future stable version (with removed/added/modified translations due to new features or fixes)
17:37:56 [luks]
what other version does it make sense to translate?
17:37:56 [zas]
using poedit and git i was always able to handle this...
17:38:11 [luks]
but people are not going to use git
17:39:01 [luks]
dropping transifex would mean having somebody to help people with editing the files and merging/committing them to git
17:40:44 [nikki]
Ben\Sput: enter a ticket then?
17:41:31 [Ben\Sput]
nikki: i was waiting for you to come say, "oh, that's already got a ticket" :)
17:41:39 [Ben\Sput]
but i couldn't find one myself
17:41:55 [zas]
luks: i'm ok with transifex, but i was not expecting it to block unit testing of translation stuff
17:42:15 [zas]
i will just disable the test
17:42:26 [nikki]
Ben\Sput: I certainly haven't seen it before :)
17:42:47 [luks]
zas: well, it's not blocking the unit tests
17:43:12 [luks]
I was saying that if you don't submit the translations to transifex after the change it merged, the translations will get lost
17:44:23 [JonnyJD]
JonnyJD has joined #musicbrainz-devel
17:46:40 [zas]
luks: but if i submit a modified-for-current-dev-tree picard.pot + fr.po, what will happen exactly ? I don't want it to modify "stable" version of translation files
17:47:15 [Mineo]
Mineo has joined #musicbrainz-devel
17:47:24 [zas]
Hey, Mineo
17:48:01 [Mineo]
no offense, but that is certainly creepy
17:51:37 [Mineo]
but hi :P
17:51:59 [zas]
what is creepy ? the __str__() thing ?
17:51:59 [Ben\Sput]
http://tickets.musicbrainz.org/browse/MBS-5765
17:52:27 [Mineo]
no, you saying hi to me a few seconds after I joined :P
17:52:36 [zas]
ah ;)
17:52:37 [Ben\Sput]
^ :P
17:52:55 [nikki]
* nikki makes a note to say hello to Mineo as soon as he joins ;D
17:53:43 [zas]
about this __str__() i can write an explicit method to replace it, but frankly what do you expect from a multi selection object to return when converted to a string ? ;)
17:53:55 [Mineo]
nikki: you're a wessi, you're creepy by definition :D
17:54:03 [nikki]
haha
17:56:20 [Mineo]
zas: well, something that tells me what the hell I'm seeing, like "available types: foo, selected types: bar" which at least guarantees you to be non-empty :)
18:00:56 [MBJenkins]
Project musicbrainz-data build #125: SUCCESS in 2 min 9 sec: http://ci.musicbrainz.org/job/musicbrainz-data/125/
18:00:56 [MBJenkins]
ollie: Add Data.Cleanup to test if an entity is eligible for automatic deletion
18:02:16 [zas]
Mineo: ok i will fix that
18:02:22 [zas]
afk for diner
18:06:26 [MBJenkins]
Project musicbrainz-data-service build #61: SUCCESS in 1 min 39 sec: http://ci.musicbrainz.org/job/musicbrainz-data-service/61/
18:06:27 [MBJenkins]
ollie: Expose /work/eligible-for-cleanup
18:10:02 [dimonov]
dimonov has joined #musicbrainz-devel
18:11:38 [sezuan]
sezuan has joined #musicbrainz-devel
18:16:56 [MBJenkins]
Project musicbrainz-data build #126: SUCCESS in 2 min 10 sec: http://ci.musicbrainz.org/job/musicbrainz-data/126/
18:16:57 [MBJenkins]
ollie: Change 'eligibleForCleanup' to use the conjunction of cleanup predicates, not disjunction
18:17:52 [luks]
zas: if I merge the branch to master, the new string will get added to transifex (as empty), fr.po will already be translated in git (because you changed it manually), then you can upload the fr.po file to transifex
18:20:30 [hawke_]
luks: I’m guessing http://acoustid.org/track/df9d0d7f-737d-4731-b46c-dc0877accb0d should not exist?
18:20:41 [hawke_]
and http://acoustid.org/track/242b79e1-00d3-4ead-b55f-4fda127d24e1
18:23:39 [luks]
wow
18:23:45 [luks]
* luks wonders how did that happen
18:24:02 [hawke_]
hehe
18:25:07 [luks]
I assume it's a result of some bad merge
18:25:25 [luks]
e.g. the fingerprints were moved, but the acoustid was not deleted
18:25:29 [MBJenkins]
Project musicbrainz-data-service build #62: SUCCESS in 1 min 41 sec: http://ci.musicbrainz.org/job/musicbrainz-data-service/62/
18:25:29 [MBJenkins]
ollie: Expose /work/eligible-for-cleanup
18:44:04 [zas]
luks: ok, for transifex stuff
18:50:35 [Freso]
zas: You can merge master into your feature branch. You'll have to apply the same cahnges manually as with a rebase, but you won't lose any history.
18:50:54 [reosarevok]
Hmm
18:51:04 [reosarevok]
Freso: apparently comma-separated didn't work either
18:51:17 [reosarevok]
(for this guy who wants not to tag album nor albumartist)
18:51:39 [nikki]
what are you trying to do?
18:52:13 [reosarevok]
Me? Answer a support mail
18:52:15 [reosarevok]
:)
18:52:18 [nikki]
well, yeah
18:52:23 [reosarevok]
One second
18:53:33 [Freso]
reosarevok: Perhaps he's running into the same issue I described in that ticket I linked?
18:54:06 [Freso]
(Blocking on "hip hop r b" also blocks "hip hop" and "r b".)
18:54:26 [reosarevok]
Freso: he wants to block *more* stuff not less anyway :p
18:54:32 [Freso]
(Or was it the other way, I forget.)
18:54:43 [reosarevok]
"- I want to exclude tags from be tagged. One exclusion is working but when I add another in the options the second isn´t noticed. (For example: "tracknumber album albumartist " only the tracknumber isn´t tagged.
18:54:43 [reosarevok]
- How can I set "Various Artists" and "[non-album tracks]" to be not tagged?"
18:54:49 [reosarevok]
Were the two questions
18:55:48 [Freso]
So, wait, tags isn't MB tags, but music file tags?
18:56:08 [hawke_]
I use $if($eq(%albumartist%,Various Artists), $unset(albumartist))
18:56:37 [hawke_]
And as for non-album tracks, just blank that and it will work fine.
18:56:44 [hawke_]
(in the metadata options)
18:57:15 [ruaok]
ruaok has joined #musicbrainz-devel
18:57:22 [reosarevok]
Freso: I did say it was a Picard question :p
18:57:39 [Freso]
reosarevok: Picard can use MB "tags as genre".
18:57:59 [Freso]
reosarevok: Which allows you to make a comma separated list of tags to exclude.
18:58:44 [reosarevok]
Oh
18:58:44 [hawke_]
…that does sound like what he’s talking about.
18:58:55 [reosarevok]
I never actually even thought our tags were good for anything
18:58:57 [reosarevok]
(MB tags)
18:59:01 [hawke_]
ah, he’s misunderstanding what the exclusion does
18:59:05 [reosarevok]
So didn't think about anyone using them :)
18:59:17 [hawke_]
he’s thinking it blocks file tags, but it blocks folksonomy tags
18:59:37 [reosarevok]
hawke_: dunno - he shared an image in which track numbers weren't being saved, so I guess he's doing *something* right somewhere?
19:00:02 [reosarevok]
(must be elsewhere though :) )
19:00:05 [hawke_]
hehe
19:03:55 [nikki]
* nikki despairs
19:05:08 [nikki]
I searched for open edits with no votes and the top two things were someone voting no to entire release because the editor followed the old feat artist style and another editor voting no to an entire release because of things that could be fixed by pressing guess case
19:05:17 [reosarevok]
hawke_: so, what should I tell the guy?
19:05:45 [reosarevok]
To put $unset(albumartist) and $unset(album) in his taggerscript?
19:05:55 [nikki]
that sounds right
19:06:02 [hawke_]
maybe explain what the “exclusions” setting is for, and give him some taggerscript
19:08:14 [reosarevok]
hawke_: that makes it sound as if I knew anything about Picard's taggerscript - I just load stuff, see if it's the right release, press save :p
19:08:29 [reosarevok]
but ok, the exclusions bit at least I think I understand :)
19:09:01 [hawke_]
reosarevok: exclusions lets you block certain folksonomy genres…$unset() should be fairly straightforward.
19:09:23 [hawke_]
Oh, and tell him to set the [non-album tracks] setting to blank, and it will not give a false title to NAT albums
19:09:40 [reosarevok]
Yeah, but how does unset work? Does he need several instances, can he just give $unset(albumartist, album, tracknumber) and it will work?
19:09:48 [hawke_]
That would be the Options/Options/Metadata/Non-album tracks: setting
19:09:58 [hawke_]
he needs several instances, one for each file tag
19:10:10 [reosarevok]
Ok
19:14:52 [ruaok]
ruaok has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: reviews, translation sorting stuff (catcat), MBS-5757 (reotab), github pull vs codereview (warp), CAA-39 (warp), nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok)
19:21:24 [reosarevok]
reosarevok has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: reviews, translation sorting stuff (catcat), MBS-5757 (reotab), github pull vs codereview (warp), CAA-39 (warp), nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki)
19:22:21 [ocharles]
that's a-lota topics
19:22:34 [ocharles]
or do I mean, that's-a lotta topics
19:22:48 [Freso]
Oh, hey, it's Monday!
19:23:09 [ocharles]
it's monday, monday, gotta get down (to #musicbrainz-devel) on monday
19:23:13 [Freso]
I need to go make soup then soon.
19:23:13 [adhawkins]
mbs-5757
19:23:14 [mb-chat-logger]
http://tickets.musicbrainz.org/browse/MBS-5757
19:23:16 [adhawkins]
caa-39
19:23:16 [mb-chat-logger]
http://tickets.musicbrainz.org/browse/CAA-39
19:23:32 [Freso]
I can't attend an IRC meeting and not be having soup.
19:23:45 [ocharles]
Freso: I should start making that a habit too!
19:23:50 [Freso]
ocharles: :)
19:28:21 [adhawkins]
Re: mbs-5757, are we condoning people borrowing a CD from a library and ripping it?
19:28:22 [mb-chat-logger]
http://tickets.musicbrainz.org/browse/MBS-5757
19:29:27 [reosarevok]
adhawkins: you mean there's any other reason to borrow a CD from a library? :p
19:29:32 [ocharles]
:P
19:29:43 [adhawkins]
To see if you like it enough to buy it?
19:30:04 [ocharles]
what's is this, the 80s?
19:30:23 [reosarevok]
Ok, true, there's also "to scan it for CAA" :p
19:30:49 [adhawkins]
reotab: If that's the reason, you don't need to worry about the 14 day wait for your edits to be applied
19:31:03 [adhawkins]
FWIW, I agree with the ticket. That justification of it is a bit dumb IMO
19:32:05 [_flow_]
_flow_ has joined #musicbrainz-devel
19:33:55 [hawke_]
adhawkins: I think it’s a fine justification: You often need to reference liner notes for ARs
19:34:16 [adhawkins]
Ok
19:34:47 [adhawkins]
But the description specifically mentions tagging and borring from a library...
19:34:54 [adhawkins]
borrowing
19:35:19 [reosarevok]
adhawkins: I seriously doubt *anyone* takes CDs from a library not to rip them (unless they dislike them)
19:35:22 [reosarevok]
Except maybe you :)
19:35:31 [adhawkins]
* adhawkins doesn't take CDs from libraries.
19:35:56 [reosarevok]
I know that's one of the problems I've seen people have with the 14 day period, so I mentioned it
19:36:06 [adhawkins]
Just pointing out that the legality of that is questionable at best :)
19:36:14 [reosarevok]
Depends on where you are
19:36:48 [hawke_]
For ripping/tagging purposes it’s not necessarily relevant, because you can always tag it later.
19:36:54 [hawke_]
(after edits go through)
19:37:03 [adhawkins]
I'd be surprised if there was anywhere it was legal to copy coprighted material that you don't already own another copy of...
19:37:13 [adhawkins]
hawke_: For tagging it's annoying though.
19:37:34 [adhawkins]
More than once I've spotted a stupid typo in a release I've just entered. To have to wait 14 days for that typo to be fixed is a bit frustrating sometimes.
19:37:37 [hawke_]
I mean the library lending duration
19:38:22 [hawke_]
you do need to have the liner notes (from the library) for AR reference — you don’t need them for ripping/tagging, because once you have the edits in you can retag later.
19:40:26 [reosarevok]
adhawkins: If I don't remember it very wrongly, in several European countries it's perfectly legal to make a copy for yourself of stuff even if you don't own it
19:40:32 [reosarevok]
Just not to redistribute it
19:41:00 [adhawkins]
reosarevok: I'm no expert, but that doesn't sound right to me.
19:41:29 [adhawkins]
In that case it'd be ok for me to take a copy of my friend's Windows DVD (ignoring the activation issue) for my own use.
19:43:08 [reosarevok]
In Spain: copying literary, artistic or scientific stuff is allowed without authorisation, as long as a) it's for private use of the copier, b) the copier has had legitimate access to the copied stuff and c) there's no profit
19:43:14 [reosarevok]
It doesn't apply to software though
19:44:15 [reosarevok]
"take it from a library" is certainly legitimate access :)
19:46:01 [reosarevok]
"stuff" is obviously not the legal word but I don't know what's the right translation :)
19:47:42 [adhawkins]
reosarevok: I'll take your word for it.
19:47:59 [adhawkins]
Must be a load of spanish musicians looking for bar work then...
19:48:21 [reosarevok]
heh
19:48:38 [reosarevok]
Pretty much as many as anywhere else
19:48:54 [reosarevok]
It's not like a law against that is enforceable
19:49:10 [reosarevok]
So in the end it pretty much doesn't matter
19:49:20 [adhawkins]
But it would deter people who tried to be honest like me :)
19:51:17 [reosarevok]
Why? If you feel it's not honest, you shouldn't do it whatever the law says. It would only deter the kind of people who follow every single written norm and yet look to check everything that is permitted :p
19:51:32 [adhawkins]
Ok, for 'honest' substitute 'law abiding'.
19:52:00 [adhawkins]
If I knew it was strictly illegal, I'd be more inclined not to do it, however slim the chances of me getting caught were.
19:52:19 [adhawkins]
Of course, that's the 40-something me talking. The teenager / 20-something me almost certainly felt differently :)
19:53:17 [ruaok]
reosarevok: thats good to know about the rules in spain.
19:53:22 [ruaok]
I have a lot to learn. :)
19:54:11 [reosarevok]
ruaok: well, those are being looked at, so it's hard to even be sure if they're still like that - I haven't looked much into it since I left since I have no intentions to go back :p
19:54:29 [ruaok]
heh. :)
19:54:35 [ruaok]
not going back evar?
19:54:41 [reosarevok]
Well, not planning to :p
19:55:01 [reosarevok]
(moving, not visiting - unlikely to go to a lot of libraries while visiting :p)
19:55:19 [jdamcd]
jdamcd has joined #musicbrainz-devel
19:55:45 [Freso]
Uh-oh.
19:55:57 [Freso]
5 mins. and water's only just boiling.
19:56:24 [ocharles]
tut, my thai curry is already done
19:56:49 [nikki]
* nikki just reheated her curry
19:57:02 [nikki]
I like how we're all planning to eat in the middle of the dev chat :P
19:57:09 [ocharles]
:)
19:57:35 [ianmcorvidae]
I've considered going to a restaurant for the dev meeting
19:57:44 [ianmcorvidae]
but I haven't done it (yet)
19:57:45 [warp]
* warp is not eating.
19:57:57 [ocharles]
ianmcorvidae: i've done a dev meeting from outside a uni bar
19:59:32 [ianmcorvidae]
heh
19:59:34 [ocharles]
"Early versions of the GCC C compiler when given a program containing the #pragma directive, which has implementation-defined behavior according to the C standard. In practice, many C implementations recognize, for example, #pragma once as a rough equivalent of #include guards — but GCC 1.17, upon finding a #pragma directive, would instead attempt to launch commonly distributed Unix games such as NetHack and Rogue, or start Emacs
19:59:34 [ocharles]
running a simulation of the Towers of Hanoi."
19:59:35 [ocharles]
amazing.
20:00:00 [ruaok]
<BANG>
20:00:03 [ruaok]
ha!
20:00:09 [ruaok]
I got before anyone could razz me about being late
20:00:15 [ruaok]
* ruaok sobs about what he's turned into
20:00:28 [ruaok]
who wants to go first?
20:00:38 [reosarevok]
You, obviously
20:00:41 [ocharles]
i can
20:00:41 [reosarevok]
Or you might be late!
20:00:56 [warp]
* warp can.
20:01:03 [ruaok]
go warp
20:01:09 [warp]
ok!
20:01:24 [Freso]
ruaok: 21:00:00 ruaok | <BANG>
20:01:26 [Freso]
:)
20:01:46 [warp]
It has just been normal ticket work last week, worked on about 10 jira issues and nothing in particular stands out.
20:02:04 [warp]
We had some trouble with hobbes being overloaded
20:02:22 [ruaok]
what was causing that?
20:02:24 [ruaok]
java? ci?
20:02:40 [warp]
no one thing.
20:02:49 [warp]
just 150% of memory being used more or less.
20:03:11 [warp]
so if things try to run at the same time too many things need to get out of swap at the same time, etc..
20:03:20 [ruaok]
I've seen the search stuff take 600% of ram before
20:03:32 [warp]
we did move the mbserver of beta.musicbrainz.org off of hobbes last week, which will help a bit.
20:03:40 [ocharles]
ruaok: that doesn't sound like java behavior at all
20:03:50 [warp]
but the beta search server is still on there.
20:04:10 [ruaok]
ocharles: being faceitous?
20:04:13 [ocharles]
</sarc>
20:04:17 [ruaok]
:-)
20:04:20 [warp]
ocharles: wasn't the beta search server also causing some unexpected postgresql disconnections?
20:04:25 [ocharles]
yea, i'll get to that though
20:04:35 [warp]
ok, I'll continue.
20:05:03 [warp]
this morning I shipped a bunch of things from code review to beta, which is causing things to fail now.
20:05:34 [warp]
afaics this is a perl 5.14 vs 5.10 issue. I spent some time debugging that today.
20:05:55 [warp]
but when I noticed it was a 5.10 thing I started installing 5.10 an my machine and walked off to do something else.
20:06:04 [warp]
ruaok: that's about it.
20:06:11 [ruaok]
ocharles: next
20:06:20 [ocharles]
ok
20:06:33 [ocharles]
My week was mostly NES fueled, with two 7Digital days
20:06:50 [ocharles]
I'm focusing on https://trello.com/board/musicbrainz-nes/50f408ce968524501800442f which has grown, shrunk, and probably grown again, in amount of tasks
20:07:06 [Ben\Sput]
Ben\Sput has joined #musicbrainz-devel
20:07:14 [Jozo]
adhawkins: http://en.wikipedia.org/wiki/Private_copying_levy
20:07:16 [ocharles]
Right now you can: create a work, edit a work, add a annotation, check for cleanups, and tag/rate works
20:07:29 [ocharles]
I'm accumulating small reviews at http://codereview.musicbrainz.org/dashboard/?view=to-group&group=NES
20:07:51 [ocharles]
ianmcorvidae asked a good question, which i'll echo here - "what are you trying to achieve with the reviews?"
20:08:01 [adhawkins]
Jozo: Great, so us people who buy stuff are funding the freeloaders? :)
20:08:10 [ocharles]
Mostly, I'm trying to get more eyes on this, and not have this entire project be something that iterates entirely in my head
20:08:23 [warp]
Jozo, adhawkins: outside the meeting please.
20:08:32 [ocharles]
we're at the stage now where I think people can start helping - ideas are mostly stable now
20:08:47 [ocharles]
for example, i've done very little performance analysis, so that could be a good project for someone to jump in with
20:09:13 [ocharles]
At the weekend, I fixed a bunch of edit search timeouts with one magical index
20:09:20 [ocharles]
so now people can view /user/foo/edits, once again
20:09:26 [ruaok]
oooh!
20:09:38 [ianmcorvidae]
well, that one's not strictly edit search, but yup :P
20:09:46 [ocharles]
in the process, I discovered the source of lines and lines of 'unexpected EOF from client' in the postgresql logs - the search servers are all to blame
20:09:52 [ruaok]
(me wonders if that was the right number of oo's)
20:10:03 [ocharles]
none of them disconnect properly, and now that the beta re-indexer kicks in every 10 minutes (or more?) it's spamming the logs
20:10:05 [ianmcorvidae]
oh, *that's* what that was, I'd just been ignoring those lines (heh)
20:10:16 [ocharles]
murdos said he will look into it, so i'll leave that with him for now
20:10:30 [ruaok]
ocharles: can you please file a ticket for that anyway.
20:10:32 [ruaok]
?
20:10:33 [ocharles]
ok
20:10:39 [ruaok]
just so we have it on record.
20:10:45 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: reviews, translation sorting stuff (catcat), MBS-5757 (reotab), github pull vs codereview (warp), CAA-39 (warp), nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki)
20:10:47 [ocharles]
today i lost a day, partly due to a maths assignment, and partly due to susie stabbing herself with a knife at 3am and me having to escort her to a7e
20:10:49 [ocharles]
a&e*
20:10:55 [ocharles]
fin :)
20:11:01 [ruaok]
a&e?
20:11:08 [ocharles]
accident & emergency
20:11:11 [ruaok]
ah.
20:11:18 [ruaok]
I'm sorry to hear that. :(
20:11:20 [ocharles]
(part of hospitals here)
20:11:25 [ruaok]
ianmcorvidae: you go!
20:11:26 [ocharles]
it's fine, she over reacted imo, but we got it dealt with :)
20:12:10 [ianmcorvidae]
okay
20:12:28 [ianmcorvidae]
lots of random stuff this week, biggest single block was making /edit/open work correctly (once again: adding one index)
20:12:53 [ianmcorvidae]
I also finally got our schema diagram updated, which has been waiting for quite a while :) fixed some errors too
20:13:18 [ianmcorvidae]
but in general just the usual stuff, some codereviews, shipping them, fixing some tests, etc.
20:13:33 [ianmcorvidae]
weekend was pretty much out, was helping to clean a house, so a bit less this week than usual
20:13:41 [ianmcorvidae]
(that's all, I think)
20:13:47 [ruaok]
thanks.
20:14:00 [ruaok]
my week was dominated with phone calls and other silly things.
20:14:05 [ruaok]
but, good things.
20:14:27 [ruaok]
moved along the conversation with spotify. they continue to be good humans, clued in and able to listen.
20:14:35 [ruaok]
which I really appreciate.
20:14:46 [ruaok]
the 7digital contract is signed, which is great.
20:14:57 [ruaok]
also, sony music uk came out of the woodworks.
20:15:21 [ruaok]
matt hawn, our director, was instrumental AGAIN in providing a sane reference for all of us data nerds.
20:15:41 [ruaok]
the sentiment at Sony UK, is that they are fine giving us their data feed.
20:15:50 [ruaok]
in exchange for a live data feed.
20:16:12 [ruaok]
they also are undertaking a "uk artist gateway" kind of project and are thinking about using us.
20:16:36 [ruaok]
interesting side story here: apparently being represented in MB is better than spendin 10k GPB on google adverts.
20:17:05 [ruaok]
since MB stuff appears at the BBC, which then gets googled and that allows data to get out faster than sony putting it on their site.
20:17:25 [ruaok]
they literally cited, great SEO results as one of the reasons for using us.
20:17:35 [ruaok]
not something I expected, for sure.
20:17:46 [warp]
:)
20:17:47 [ocharles]
indeed
20:17:59 [nikki]
cool
20:18:00 [ruaok]
I'm also continuing the coversation with last.fm over some data, but more on that later.
20:18:09 [ianmcorvidae]
heh, good SEO by proxy on our part
20:18:18 [ruaok]
and then, I spend 2 two hour meetings with freso & the mbo clan.
20:18:24 [ruaok]
(over the weekend)
20:18:27 [Freso]
\m/
20:18:33 [ruaok]
but I will let Freso talk about that more.
20:18:39 [Freso]
Uh-oh.
20:19:07 [ruaok]
we're also gooing to sponsor the SF Music Tech summit again.
20:19:42 [ruaok]
and the rate of notice and inquiries after the conference last time was really really good, so its a good way to spend a trifle of money on publicity.
20:20:02 [ruaok]
and, I have the best of intentions to get the changed-id feeds out, but… well, ya.
20:20:09 [ruaok]
I'll keep trying. it doesnt need much.
20:20:14 [ruaok]
thats it for me.
20:20:17 [ruaok]
Freso?
20:20:20 [Freso]
Sure.
20:20:49 [Freso]
As Rob said, we've had some MBo meetings over the weekend, to try and make goals/vision and roadmap a bit clearer.
20:20:58 [Freso]
Both for me and Caller#6, but also everyone else.
20:21:04 [Freso]
https://github.com/Freso/MusicBottle/wiki/Goals-and-vision
20:21:10 [ruaok]
* ruaok thinks there were good meetings
20:21:10 [Freso]
is what's available so far.
20:21:25 [Freso]
The roadmap and such will be pretty typed and put up... eventually. :)
20:21:32 [Freso]
Codewise...
20:21:32 [ruaok]
ha. :)
20:21:46 [Freso]
I've started implementing more tests, with help from warp (cheers!).
20:22:04 [Freso]
And Caller#6 has made our current pre-pre-alpha test site a bit more appealing:
20:22:14 [Freso]
http://musicbottle.mbsandbox.org/
20:22:30 [Freso]
We've also played around a bit with the code workflow, so, yeah...
20:22:37 [Freso]
Things are moving, however slowly. :)
20:22:39 [Freso]
Oh.
20:22:48 [Freso]
And I've started a physics course per today.
20:23:04 [Freso]
So between being at classes and doing homework, my activity/availability may drop a bit.
20:23:06 [Freso]
Just FYI.
20:23:08 [ruaok]
fun. :)
20:23:10 [Freso]
/done
20:23:16 [ruaok]
oh, speaking of availabilty.
20:23:19 [ocharles]
* ocharles will stick to the abstract maths
20:23:27 [Ben\Sput]
F=ma!
20:23:35 [ruaok]
today is a bank holiday here in the US, so I'll be offline most of the afternoon.
20:23:42 [ocharles]
enjoy!
20:23:48 [ruaok]
and I am going to ORD camp in chicago again over the weekend.
20:23:55 [Freso]
(he says at half past 9pm...)
20:24:06 [ruaok]
traveling on thu, spottily online friday.
20:24:10 [ruaok]
not online over the weekend.
20:24:17 [ruaok]
traveling home on monday.
20:24:32 [ruaok]
I need to see about the meeting, if I can make it.
20:24:47 [ruaok]
so, if you need something from me, tomorrow and wed are the best times to nab me.
20:24:51 [ruaok]
ok, who else for review?
20:25:15 [ruaok]
* ruaok wont push hard there are lot of other topics
20:25:18 [ruaok]
onward then.
20:25:18 [warp]
on this topic. we have a recording meeting on wednesday, correct? I'll be traveling, I'll try to join from the train but no promises.
20:25:30 [ruaok]
warp: yes, standard meeting time.
20:25:43 [ruaok]
CatCat: are you about for translation sorting?
20:25:55 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: translation sorting stuff (catcat), MBS-5757 (reotab), github pull vs codereview (warp), CAA-39 (warp), nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki)
20:26:21 [Freso]
I haven't seen any activity from CatCat at all today, I think.
20:26:21 [ruaok]
lets move on to MBS-5757, reosarevok. for now. we can come back if catcat appears.
20:26:22 [mb-chat-logger]
http://tickets.musicbrainz.org/browse/MBS-5757
20:26:27 [Freso]
+1
20:26:28 [reosarevok]
Ok!
20:26:47 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: MBS-5757 (reotab), github pull vs codereview (warp), CAA-39 (warp), nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki), translation sorting stuff (catcat)
20:27:10 [reosarevok]
So, pretty much what it says on the ticket - there doesn't seem to be a particularly big benefit over our current 14 days open edit period
20:27:19 [reosarevok]
s/over/from
20:27:24 [reosarevok]
Over the previous 7 day one
20:27:32 [reosarevok]
But that was changed way before I was involved
20:27:38 [reosarevok]
So: first question is why :)
20:27:56 [ocharles]
i think it was before me too
20:28:13 [Freso]
* Freso can't remember it being 7 days
20:28:14 [ruaok]
I can't even remember.
20:28:26 [warp]
before I was involved I think.
20:28:26 [ruaok]
I always thought it was 2 weeks.
20:28:30 [reosarevok]
heh
20:28:30 [ruaok]
but its been too long.
20:28:39 [warp]
anyway, +1 on this change.
20:28:41 [nikki]
it used to be one week
20:28:41 [reosarevok]
Ok. nobody knows
20:28:51 [nikki]
it was changed at the same time as data quality
20:28:53 [ocharles]
i imagine the majority of our edits pass with 0 votes anyway
20:28:57 [reosarevok]
Question 2: anyone has a reason why it should keep being 2 weeks :)
20:28:58 [ocharles]
does that conjecture seem true?
20:29:14 [ianmcorvidae]
most of our edits certainly pass on expiration, not sooner
20:29:15 [ruaok]
reosarevok: what do you suppose this gains us?
20:29:19 [nikki]
ocharles: I don't think so
20:29:20 [ruaok]
just moving along at a faster rate
20:29:21 [ruaok]
?
20:29:21 [ianmcorvidae]
I think there's a subset that get one vote or so
20:29:26 [nikki]
ocharles: they don't tend to get 3 votes, but a lot of edits do get one
20:29:29 [reosarevok]
ruaok: one less week of annoyance for non-auto-editors
20:29:29 [warp]
ruaok: happier users, especially non-autoeditors.
20:29:34 [ocharles]
nikki: ok, that's interesting to know
20:29:36 [ruaok]
warp: ok.
20:29:40 [ruaok]
I'm ok with that.
20:29:41 [ianmcorvidae]
theoretically, could also shrink the edit queue somewhat
20:29:48 [ruaok]
does anyone have a strong objection to that?
20:29:51 [nikki]
note that if we change it, modbot is goign to suddenly have a LOT of edits to close
20:29:58 [ocharles]
i'm for it
20:30:01 [ruaok]
which is practical psychological impacts
20:30:05 [ianmcorvidae]
nikki: don't think so, expiration time is set when the edit is *open*, I think?
20:30:14 [ruaok]
ianmcorvidae: yep.
20:30:18 [nikki]
ianmcorvidae: hmm
20:30:22 [nikki]
ianmcorvidae: ok then, that's ok
20:30:26 [ruaok]
so modbot won't know the difference.
20:30:29 [Freso]
Wait, so, are we decreasing *all* edit times - or just non-destructive ones?
20:30:31 [ianmcorvidae]
(i.e. making this change won't change any expiration times for edits that are already open, so, yup)
20:30:36 [Freso]
(Ie., not merges, deletes, etc.)
20:30:49 [reosarevok]
Yeah, that's a good question 3!
20:30:50 [ocharles]
Freso: i read it as all
20:30:54 [reosarevok]
Thanks Freso :)
20:31:05 [warp]
different expire times are confusing, I say for all.
20:31:12 [ruaok]
+1
20:31:19 [ocharles]
i agree, but it could be good to see what the impact is with just edits for a while
20:31:20 [ruaok]
we can always go back if we want to change it.
20:31:29 [ruaok]
this is a trivial change to put in place.
20:31:44 [ruaok]
let's do this and see.
20:31:53 [ocharles]
is the this all, or non-destructive?
20:31:56 [ruaok]
also, are we allowing /release in robots.txt ?
20:31:59 [ruaok]
all
20:32:00 [warp]
yeah, we just need to revert that commit in 2007 then rebase everything else on top of that.
20:32:03 [warp]
;)
20:32:03 [nikki]
ruaok: no, we're not
20:32:06 [ianmcorvidae]
haha
20:32:13 [ocharles]
warp: lol
20:32:14 [Freso]
warp: +1
20:32:14 [ruaok]
should we?
20:32:14 [nikki]
it was artists, labels and release groups last I checked
20:32:16 [nikki]
yes!
20:32:24 [ruaok]
I think we should.
20:32:25 [warp]
ruaok: yes.
20:32:32 [Freso]
ruaok: +1
20:32:34 [ruaok]
nikki: would you please make a ticket for that too?
20:32:40 [reosarevok]
Hmm
20:32:42 [nikki]
just /release/?
20:32:49 [ruaok]
wiat.
20:32:56 [ruaok]
release-group.
20:33:05 [nikki]
release group is already done
20:33:06 [ruaok]
release-group for sure. not sure about releases.
20:33:10 [ruaok]
ah, ok.
20:33:14 [reosarevok]
That reminds me I was wondering whether we'd want to close MB again if/when MBo is out
20:33:21 [ruaok]
then I would say /release
20:33:28 [reosarevok]
But that's probably a (long into the) future discussion :)
20:33:29 [ruaok]
reosarevok: let talk about that when the time comes. )
20:33:35 [Freso]
reosarevok: We'll talk about that then...
20:33:46 [ruaok]
any suggestions for other things to open?
20:34:02 [reosarevok]
work?
20:34:06 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: github pull vs codereview (warp), CAA-39 (warp), nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki), translation sorting stuff (catcat)
20:34:07 [nikki]
work!
20:34:13 [ruaok]
I'm fine with that.
20:34:22 [ruaok]
I think I would be fine with just about everything except recordings.
20:34:33 [nikki]
what about isrc?
20:34:39 [nikki]
that's sorta recordings sorta not
20:34:49 [ruaok]
lets turn this on its head.
20:35:02 [ruaok]
who is against allowing everything except recordings?
20:35:11 [ocharles]
any reason you don't want recordings?
20:35:12 [nikki]
everything being all entities or what?
20:35:13 [Freso]
Eh.
20:35:15 [Freso]
-1
20:35:16 [warp]
ruaok: I think by now we can allow everything.
20:35:17 [Freso]
:p
20:35:21 [ocharles]
i'm with warp
20:35:22 [ruaok]
ocharles: that is a LOT of pages.
20:35:32 [ruaok]
that would basically be tar-pit for the crawler.
20:35:45 [ocharles]
that's not our problem :)
20:35:47 [ocharles]
is it?
20:35:48 [ruaok]
nikki: everything being all entities.
20:35:48 [nikki]
https://musicbrainz.org/robots.txt is the current robots.txt btw
20:36:12 [reosarevok]
ocharles: well, it might make sense for it to index all works etc before it gets mired in recordings
20:36:12 [nikki]
I'm fine with opening up release, work and url (which are the remaining non-recording entities)
20:36:21 [ruaok]
ocharles: not sure. does that preclude the bot from indexing new stuff when an existing instance is going to find stuff for a couple more years?
20:36:24 [reosarevok]
url sounds a bit pointless...
20:36:36 [warp]
I guess releases are also quite a lot, let's do those first as usual and see if we can manage the load.
20:36:39 [ocharles]
ruaok: a couple of years? google could trawl all million pages in days, i would bet
20:36:56 [ruaok]
ocharles: their crawlers are rate limited.
20:37:11 [ruaok]
so at 1 request per second, you do the math.
20:37:15 [ocharles]
yea, they obviously aren't going to do it that fast, but i would think weeks not months
20:37:19 [ocharles]
and i highly doubt they are first in first out
20:37:25 [ruaok]
nikki: go ahead and make a ticket for everything, but recordings.
20:37:26 [ocharles]
new content will probably be evenly distributed
20:37:31 [nikki]
ruaok: with or without urls?
20:37:42 [warp]
with
20:37:45 [ruaok]
I'd say with. why not?
20:37:56 [ruaok]
ok, lets move on. too much left.
20:37:56 [ocharles]
ruaok: well the math says 2 weeks :p
20:38:03 [ocharles]
but yea, i'm cool with this plan
20:38:05 [nikki]
well, urls are shown on entity pages already
20:38:12 [ruaok]
github, warp!
20:38:13 [nikki]
so we don't really need them to be crawled
20:38:37 [warp]
alright, we've been trying github pull requests a bit over the past few weeks.
20:38:51 [ruaok]
ocharles: 2 weeks? 115 days by me math.
20:38:55 [ruaok]
*my
20:38:56 [warp]
luks' oauth patch is on there for us to get some idea how it works with a larger patch
20:39:16 [warp]
I'm happy with it, I'd like to switch
20:39:28 [warp]
what do you all think?
20:39:33 [ocharles]
https://www.google.co.uk/search?q=1+million+seconds+in+days&oq=1+million+seconds+in+days&aqs=chrome.0.57j60j59j62l3.8709&sugexp=chrome,mod=4&sourceid=chrome&ie=UTF-8 :)
20:39:44 [reosarevok]
ocharles: we have 10 mill recordings
20:39:46 [Freso]
* Freso has been doing reviewing etc. for MBo on GitHub as well, and would +1 a switch based on that
20:39:47 [ocharles]
oh, 10 mil
20:39:48 [reosarevok]
Don't we?
20:39:49 [ocharles]
heh
20:39:56 [ocharles]
but this is o/t
20:40:01 [reosarevok]
yep
20:40:15 [ianmcorvidae]
I honestly still like codereview better, but I understand we don't want to maintain it, so I'm fine with switching on that basis
20:40:26 [ocharles]
i'm not against switching, nor particularly for
20:40:26 [reosarevok]
I use cr rarely enough that I don't particularly mind either :)
20:40:33 [warp]
* warp loathes the musicbrainz codereview.
20:40:37 [ocharles]
i like the lack of friction to submit reviews, but code review still has better annotating tools
20:40:53 [ruaok]
ocharles: we have 11,964,593 recordings. you're off by an order of magnitude.
20:41:10 [ocharles]
CR has code blocks, side-by-side diff, a more readable comment history
20:41:17 [ocharles]
but github is not bad, i could live with it
20:41:19 [ianmcorvidae]
ocharles: yeah, agreed, those are my concerns too
20:41:29 [Freso]
We *could*...
20:41:31 [ianmcorvidae]
but I'm in the same boat; I don't particularly care either way
20:41:41 [ruaok]
does anyone OBJECT to doing this?
20:41:48 [Freso]
Try and switch *completely* to GitHub for a month or two. Perhaps past the schema change?
20:41:57 [Freso]
Then see what people feel?
20:42:05 [ruaok]
sounds reasonable.
20:42:13 [ruaok]
let's do that.
20:42:22 [ocharles]
do we do anything with current review history?
20:42:30 [Freso]
Just let it sit there?
20:42:31 [ruaok]
leave it be for now.
20:42:36 [ocharles]
i'm also concerned about losing that, because I do still reference it
20:42:41 [ruaok]
we can archive it to flat html later if we want.
20:42:51 [ruaok]
that way we dont have to host a copy of CR ourselves.
20:42:56 [ruaok]
* ruaok wants less hosting
20:43:07 [ruaok]
CAA-39, warp!
20:43:07 [mb-chat-logger]
http://tickets.musicbrainz.org/browse/CAA-39
20:43:22 [warp]
ah
20:44:02 [warp]
for the coverartarchive we materialize some data to an index.json at the internet archive, we serve (well, redirect) this on coverartarchive.org
20:44:18 [reosarevok]
reosarevok has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: CAA-39 (warp), nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki), translation sorting stuff (catcat)
20:44:46 [warp]
but we've had a few times already that something was wrong with the files we've written, and to change something in them, we need to write all of them again.
20:45:27 [warp]
as we have another one of these issues, I think we should discuss making this dynamic in the coverart_redirect python server thing.
20:46:01 [nikki]
would we stop writing the .json files to IA then?
20:46:01 [warp]
opinions? :)
20:46:09 [warp]
nikki: yes.
20:46:10 [ocharles]
nikki: yes
20:46:17 [nikki]
I thought they use them
20:46:25 [ocharles]
i thought they use the .xml
20:46:28 [warp]
we write an .xml file for them.
20:46:36 [nikki]
there was one case where we didn't have a json file and there were no thumbnails generated until we did
20:47:03 [nikki]
I guess we should at least double check with them first
20:47:14 [warp]
yeah, if they use them then it's probably the easiest to keep doing that and keep writing the files :S
20:47:33 [ocharles]
if they are using it, then i'd still like to know what the .xml is for
20:47:36 [ruaok]
nikki: wanna contact hank and ask him?
20:47:44 [nikki]
I can do
20:47:48 [ianmcorvidae]
the .xml is just a copy of what we put out of our webservice
20:47:51 [ianmcorvidae]
they're two distinct sets of data
20:47:56 [ruaok]
ok, then based on that we can move on from there.
20:47:56 [ocharles]
i know
20:48:00 [ocharles]
but i'd like to know why it's there
20:48:13 [ruaok]
the XML is there so their indexers can consume it.
20:48:15 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: nes & transactions (ocharles), schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki), translation sorting stuff (catcat)
20:48:18 [ruaok]
for search purposes.
20:48:21 [ocharles]
right, that was my understanding
20:48:27 [ruaok]
ocharles: NES, and transactions
20:48:33 [ianmcorvidae]
see http://archive.org/details/mbid-dbff5985-2a86-4e8c-abd5-c204792d5ba3 -- note the external identifiers, language, creator/etc.
20:48:42 [ocharles]
ok, so musicbrainz-server is starting to talk NES
20:48:55 [Freso]
\o/
20:48:58 [ocharles]
as agreed, we're doing this by exposing the haskell library via a in-the-middle HTTP service
20:49:10 [ocharles]
but there's a slightly snag - the current approach is giving up transactions
20:49:28 [ocharles]
for example, to create a new work you need to open an edit, then create a work - and that currently happens in two transactions
20:49:44 [ocharles]
if you open an edit, then throw an exception, you end up with an edit with no changes
20:50:28 [ocharles]
i'm not sure what to do about this - we can: a) live with it, b) add 'open transaction' to the service and pass around transaction tokens or c) rewrite every single transaction as a single HTTP call
20:50:35 [ocharles]
I don't think c) is even possible
20:50:53 [ruaok]
doesn't postgres have nested transactions, or am I hallucinating that?
20:51:00 [warp]
ocharles: how hard would it be to garbage collect them in a) ?
20:51:03 [ocharles]
ruaok: those transactions live in an entirely separate process
20:51:10 [ocharles]
warp: you mean b?
20:51:16 [ocharles]
oh, garbage collect the edits
20:51:19 [ocharles]
that's just one example
20:51:32 [ocharles]
you will have to consider every possible failure path and do garbage collection
20:51:45 [warp]
ocharles: so, "hard" is the answer? :)
20:51:45 [ruaok]
* ruaok thinks thats kinda fugly
20:51:52 [ocharles]
ruaok: musicbrainz-server does a POST to the service, which opens a transaction, does work, commits, and responds to the request
20:52:01 [ocharles]
warp: not hard... just... "involved"
20:52:05 [warp]
haha
20:52:12 [ocharles]
ruaok: so, you make 2 calls - you get 2 (linear) transactions
20:52:22 [ruaok]
then I would vote for B.
20:52:38 [ocharles]
b) would mean you do '/open-transaction' and get a 'transaction' token, which you have to pass to all your future requests
20:52:45 [ruaok]
with a timeout in case something looses the open transaction. :)
20:52:47 [warp]
I agree b) sounds the most sensible from the options.
20:52:52 [ocharles]
if the service notices a transaction open for more than x seconds, then BAHM. you just lost your token
20:53:18 [ocharles]
ok. it should be easy to add in - it's just an extra required api parameter
20:53:18 [ruaok]
so would a transaction stay open for a long time in this case
20:53:19 [ruaok]
?
20:53:32 [ruaok]
if not, then I see no problem with this.
20:53:36 [ocharles]
ruaok: not much longer than the current implementation
20:53:44 [ocharles]
other than the constant cost of a round trip to the service
20:53:46 [ruaok]
ok, then plan b sounds best.
20:53:48 [ocharles]
(most api calls on my laptop are done in 0.003s)
20:54:01 [ruaok]
onward?
20:54:04 [ocharles]
ok, i'll go with that plan
20:54:05 [ocharles]
onward!
20:54:09 [warp]
ocharles: can't you do it without an extra call?
20:54:15 [ruaok]
schema change release, warp.
20:54:31 [ruaok]
I should note that starting this process is on the calendar for next week.
20:54:47 [warp]
ruaok: yes, I thought you said february
20:55:05 [ruaok]
yep. anything for us to cover now?
20:55:23 [warp]
ruaok: one of the things I'm interested to know is if we can move to postgresql 9.x. can you ping customers on their progress with moving away from postgres 8?
20:55:49 [ruaok]
good question.
20:55:52 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: schema change release (warp), last.fm data (ruaok), ultra-strict no-voting (reotab, nikki), translation sorting stuff (catcat)
20:55:53 [ruaok]
I'll do that this week.
20:56:08 [warp]
ok, do you need a ticket? :)
20:56:18 [ruaok]
naw, noted in my GTD.
20:56:22 [ruaok]
onward, to me.
20:56:26 [warp]
great. that's all on this topic from me.
20:56:27 [ocharles]
<3 9
20:56:37 [ruaok]
I agree its, time.
20:56:38 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: last.fm data (ruaok), ultra-strict no-voting (reotab, nikki), translation sorting stuff (catcat)
20:56:41 [ruaok]
ok, onward.
20:56:51 [ruaok]
last.fm gave us some data of stuff missing from MB.
20:57:06 [ruaok]
its riddled with classic last.fm data muddle.
20:57:22 [ruaok]
which includes conflicts between communities.
20:58:00 [ruaok]
we would need to apply our data-clean up techniques to this data to remove a pile of false posives.
20:58:05 [ruaok]
false negatives?
20:58:15 [Freso]
true positives
20:58:17 [ruaok]
my question is this. do we want to spend time doing this?
20:58:46 [ruaok]
nikki, ianmcorvidae: you've looked at the data and had some thoughts.
20:59:09 [ruaok]
maybe not right for this meeting, but we should decide what we want to do with this data and if we want pursue this.
20:59:24 [ruaok]
I'll just move along then.
20:59:35 [ianmcorvidae]
well, last time I looked at it you told me they were looking to do more data cleanup :)
20:59:48 [ruaok]
ianmcorvidae: and they said no.
20:59:51 [ianmcorvidae]
ah.
20:59:56 [ianmcorvidae]
well then
20:59:59 [ruaok]
so, the ball is back in our park. do we want to spend time cleaning?
21:00:05 [nikki]
cleaning how?
21:00:14 [ianmcorvidae]
I'll look at it again and prod you about it, then; I didn't look deeply since it was supposedly going to get less bad
21:00:14 [ruaok]
nikki: remember the two bugs you filed?
21:00:18 [nikki]
yes
21:00:19 [reosarevok]
Dropping stuff that matches aliases, etc
21:00:32 [ruaok]
we would have to apply those to the data we get from them and then import the data into geordi.
21:00:42 [ruaok]
they are not going to do any more cleanup beyond what they have given us.
21:00:47 [nikki]
btw hank says IA are using the json to determine which image to treat as the front cover for an item
21:01:12 [warp]
nikki: thanks.
21:01:14 [ruaok]
ianmcorvidae: ok, please do that and then lets discuss next week.
21:01:24 [ruaok]
no-voting: reosarevok, nikki
21:02:05 [reosarevok]
So, we feel there is a bit too much no-voting going on
21:02:21 [ruaok]
in general or are there some people that specialize in this?
21:02:32 [ruaok]
should we disable the no button for some people, some of the time?
21:02:35 [ruaok]
* ruaok runs
21:02:37 [warp]
haha
21:02:42 [ianmcorvidae]
heh
21:02:47 [reosarevok]
As in, release adds are being rejected for not following the current feat. guideline or, in some cases, even by not matching case guidelines which can be fixed with a click of the guess case button
21:02:49 [nikki]
there are some people who want everything to be perfect, it seems
21:02:55 [reosarevok]
Yeah, pretty much that
21:02:59 [ianmcorvidae]
and who won't fix it themselves :P
21:03:01 [reosarevok]
(but don't want to make it perfect themselves)
21:03:02 [ocharles]
and i'm not even voting
21:03:09 [warp]
lol ocharles
21:03:17 [ruaok]
ok, I feel that its being going on for too long.
21:03:39 [ruaok]
should I make a blog post that says: "too much no voting. accept something if it makes things better. it doesn't have to be perfect"?
21:03:59 [ruaok]
maybe make a suggestion to tag imperfect things with "needs-moar-work"?
21:03:59 [Ben\Sput]
ruaok: but how many of the offending editors are likely to read the blog?
21:04:07 [ocharles]
well nes does make this less of a problem...
21:04:09 [reosarevok]
ruaok: we have a "low quality" level...
21:04:12 [ocharles]
can we hang on and try and figure it out from there?
21:04:14 [reosarevok]
(it's just that nobody uses is :p)
21:04:14 [ocharles]
or do we need solutions now?
21:04:17 [reosarevok]
*it
21:04:19 [ruaok]
Ben\Sput: you can page slap the no voters with the url
21:04:31 [Freso]
Ben\Sput: You ca... what ruaok said.
21:04:35 [warp]
I think an e-mail to mb-users, mb-autoeditors and the forums should be sufficient.
21:04:38 [reosarevok]
ocharles: well - we can wait, it's just that it feels like it'll probably scare new users away
21:04:44 [ocharles]
* ocharles nods
21:04:50 [nikki]
the blog seems like a weird place to do it. I always saw that as being a way to interact with the outside world, not with the community
21:04:52 [ruaok]
ocharles: I think stressing to people that they should not be that strict is probably a good idea.
21:05:04 [Freso]
ruaok: +1
21:05:07 [Freso]
nikki: +1
21:05:16 [ruaok]
users, auto-editors, forums. not style?
21:05:28 [reosarevok]
Sounds right to me
21:05:45 [nikki]
users, automods, forums sounds fine
21:05:49 [ruaok]
if there are no objections, I'll do that.
21:05:51 [Freso]
nikki: +1
21:05:52 [warp]
ruaok: sure, cc style as well. though I expect most of those are reading either mb-autoedits, mb-users or both :)
21:05:52 [ianmcorvidae]
we do need something to link to -- I guess the forum thread? but something on the wiki might be better
21:06:04 [nikki]
we have mailing list archives
21:06:12 [ruaok]
thanks for your time everyone!
21:06:19 [reosarevok]
ruaok: maybe pass the text through us before posting ;)
21:06:19 [ruaok]
I'm amazed we got through all the topics. :)
21:06:21 [ruaok]
well done.
21:06:23 [Freso]
Can I ask one quick question?
21:06:25 [ruaok]
reosarevok: ok, will do.
21:06:27 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: translation sorting stuff (catcat)
21:06:29 [ruaok]
Freso: 10 seconds.
21:06:29 [Freso]
About CatCat's thing?
21:06:29 [reosarevok]
Freso: yes
21:06:31 [nikki]
Freso: no
21:06:34 [reosarevok]
That's two
21:06:34 [reosarevok]
:p
21:06:40 [warp]
>_<
21:06:42 [reosarevok]
If you know what the thing *is*, then do
21:06:46 [Freso]
Can I ask CatCat to post their thoughts to some mailing list instead of at the dev. meeting?
21:06:49 [reosarevok]
(I just don't know what it is)
21:06:50 [Freso]
If so, which?
21:07:02 [nikki]
I thought he didn't like mailing lists
21:07:06 [Freso]
(In case CatCat repeatedly won't be able to attend the meeting.)
21:07:15 [nikki]
anyway, writing something and putting it somewhere makes sense
21:07:19 [reosarevok]
Yeah
21:07:20 [nikki]
as long as someone else knows where
21:07:22 [warp]
or wiki talk page or forum post.
21:07:29 [warp]
* warp nods.
21:07:34 [Freso]
nikki: But if he can't attend the meeting, he'll need to communicate his topic asynchornously.
21:07:36 [Freso]
...
21:07:42 [Freso]
spelled right..
21:07:44 [Freso]
>_>
21:07:48 [nikki]
wiki page works for that
21:07:49 [ruaok]
ok, lets officially close the meeting.
21:07:50 [nikki]
so does the forum
21:07:53 [Freso]
Alright.
21:07:56 [ruaok]
you can continue to argue this later. :)
21:07:57 [ruaok]
</BANG>
21:07:57 [MBChatLogger]
MBChatLogger has changed the topic to: http://musicbrainz.org/#devel
21:07:59 [warp]
warp has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: translation sorting stuff (catcat)
21:07:59 [ruaok]
thanks everyone!
21:08:11 [Freso]
Freso has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: reviews, translation sorting stuff (catcat)
21:09:06 [Ben\Sput]
Don't forget people, recordings deathmatch #2 on Wednesday ;)
21:09:29 [ruaok]
Ben\Sput: put it into the topic
21:09:49 [warp]
send mail to mailinglists and notify the forums!
21:09:50 [Ben\Sput]
* Ben\Sput doesn't want to blow anything up
21:10:42 [Freso]
Freso has changed the topic to: IGLOO week | http://musicbrainz.org/#devel | agenda: reviews, translation sorting stuff (catcat) | recordings deathmatch (2012-01-23)
21:11:04 [Freso]
* Freso blows up the channel
21:11:05 [Freso]
D:
21:11:37 [Ben\Sput]
ahh ok, i wasn't sure where to put it :)
21:12:16 [Freso]
Ben\Sput: WP:BB
21:12:48 [Freso]
It's not like there aren't people around who could fix b0rkage.
21:13:09 [Ben\Sput]
* WP:BB ?
21:13:42 [Freso]
Ben\Sput: https://en.wikipedia.org/wiki/WP:BB
21:14:14 [Ben\Sput]
sounds good :P
21:14:34 [ruaok]
ianmcorvidae: I have a file on hobbes for ijabz he needs to copy off to his local machine.
21:15:00 [ruaok]
he ssh'es to hobbes using: ssh ijabz@zaphod.musicbrainz.org -p 10018
21:15:06 [ijabz]
i have ssh access, but can't get scp working
21:15:29 [ruaok]
scp -l100 ijabz@zaphod.musicbrainz.org:debug_info.tar.bz2 -p10018
21:15:30 [ianmcorvidae]
scp -P 10018 ijabz@zaphod.musicbrainz.org:/path/to/the/thing/on/hobbes .
21:15:33 [ruaok]
does not work.
21:15:38 [ianmcorvidae]
it's uppercase for scp
21:15:40 [ruaok]
oh -P
21:15:41 [ianmcorvidae]
* ianmcorvidae recommends using man pages :P
21:15:41 [ruaok]
hah!
21:15:48 [ruaok]
lol, snap. :)
21:15:59 [Prophet5]
Prophet5 has joined #musicbrainz-devel
21:16:36 [ruaok]
ocharles, ianmcorvidae, warp : you guys are working bug fixing tickets this week, right?
21:17:11 [warp]
ruaok: yes. and last week. and the week before that. and the week ...
21:17:14 [warp]
;)
21:17:15 [ianmcorvidae]
I can be, yes
21:17:29 [ruaok]
warp: :)
21:17:31 [ruaok]
ianmcorvidae: please do.
21:17:38 [ruaok]
ocharles: you as well, please.
21:17:45 [ruaok]
we need to work on the open bug count a little
21:17:45 [ocharles]
ruaok: i'd still really like to focus on nes...
21:17:51 [ocharles]
alright
21:17:56 [ruaok]
understod, but give us a couple of days, please.
21:17:59 [warp]
I'd also like to have time for NES.
21:18:06 [ocharles]
hey, i closed one over the weekend :P
21:18:13 [ruaok]
its not exactly fair to have everyone else on bugs all the time.
21:18:17 [ocharles]
agreed
21:18:20 [Ben\Sput]
an easy one to fix: http://tickets.musicbrainz.org/browse/MBS-5765 :)
21:18:36 [ruaok]
warp: lets get the open bug count down a little and then we can have you spend time on NES
21:20:03 [ijabz]
heh, well I'm clearly being dense but scp -P 10018 -l100 ijabz@zaphod.musicbrainz.org:debug_info.tar.bz2 fails with invalid syntax
21:20:25 [ocharles]
what's -l100?
21:20:34 [ocharles]
and you haven't specified a target for that file
21:20:34 [ijabz]
limit to 100kb/s
21:20:37 [ocharles]
(yo uprobably want '.')
21:20:48 [ianmcorvidae]
and yeah, you need to specify the destination
21:21:05 [ianmcorvidae]
just add ' .' to the end :)
21:21:24 [ijabz]
thx it was '.' , man page not exactly clear on that imo
21:21:52 [ocharles]
yea, i guess that synopsis is a bit unclear
21:29:13 [warp]
just remember it is exactyl like regular 'cp' :)
21:29:16 [ocharles]
yea
21:29:41 [ocharles]
in fact, you can even alias cp = scp :)
21:31:01 [ianmcorvidae]
I prefer rsync anyway
21:31:09 [ianmcorvidae]
(even locally)
21:31:18 [ianmcorvidae]
but the file specification is slightly different with rsync
21:31:45 [warp]
with rsync I always have to fiddle with getting the destination folder right if it already exists.
21:31:53 [ocharles]
* ocharles goes to read "Can Programming Be Liberated from the von Neumann Style?"
21:31:54 [ocharles]
cya!
21:33:48 [warp]
I think "rsync foo/bar here/bar" is different from "rsync foo/bar here/bar/", but I'm not sure. does it matter in either case of the here/bar folder already exists?
21:34:19 [warp]
s/of/if/
21:34:28 [ianmcorvidae]
in general how I use rsync is
21:34:36 [ianmcorvidae]
a.) make the containing folder ahead of time, always
21:34:42 [ianmcorvidae]
b.) trailing slash on the destination
21:35:39 [Ben\Sput]
ianmcorvidae: I've found it's better not to use a trailing slash in some circumstances
21:35:55 [ianmcorvidae]
and then something like 'rsync file.ext some@location:with/a/trailing/slash/' results in file.ext ending up in the specified directory
21:36:03 [Ben\Sput]
generally when you don't want to delete sub-folders in the target folder, use a slash
21:36:22 [ianmcorvidae]
I always use the trailing slash because then it's easy to remember how it works
21:36:30 [ianmcorvidae]
the other cases aren't really that relevant
21:36:36 [Ben\Sput]
eg. rsync /music/* /other/music/ vs rsync /music /other/music
21:37:19 [Ben\Sput]
... it would help if I got it right :P
21:37:29 [Ben\Sput]
* eg. rsync /music/* /other/music/ vs rsync /music /other/
21:37:39 [Ben\Sput]
which isn't really about the trailing slash, so nvm
21:37:41 [Ben\Sput]
:P
21:37:59 [ianmcorvidae]
exactly :P
21:38:46 [Ben\Sput]
yeah I always use trailing slash :)
21:46:22 [zas]
is there a reason for picard to stick to python 2.6 ?
21:48:40 [Freso]
zas: It's the latest stable Python?
21:48:58 [bitmap]
ianmcorvidae: did anything change on rika recently that might've broken my sandbox? it 502s but I don't see any errors in any logs
21:49:00 [Freso]
Well, Python 2.
21:49:08 [ianmcorvidae]
bitmap: restart the server
21:49:15 [ianmcorvidae]
bitmap: I had to kill some servers because I updated the static DB
21:49:15 [bitmap]
I did :/
21:49:22 [ianmcorvidae]
hm
21:49:26 [ianmcorvidae]
* ianmcorvidae goes to investigate then
21:49:31 [Freso]
I guess not.
21:49:58 [Freso]
* Freso thought Python operated with even/uneven version numbers like some other projects
21:50:34 [Freso]
zas: Anyway. Some backwards distributions still ship with 2.6 as their python2.
21:50:49 [Freso]
I don't know if Ubuntu update to 2.7 with 12.10.
21:50:50 [ianmcorvidae]
bitmap: there's errors in /var/log/mbsandbox-bitmap.error.log
21:50:59 [Freso]
But IIRC 12.04 shipped with 2.6.
21:50:59 [ianmcorvidae]
bitmap: specifically, though, you're going to need to update your DBDefs to the new system
21:51:13 [ianmcorvidae]
bitmap: add 'use parent 'DBDefs::Default';' to lib/DBDefs.pm
21:51:29 [ianmcorvidae]
but what it's specifically complaining about is that DETERMINE_MAX_REQUEST_TIME is missing
21:51:32 [Jozo]
Freso: https://wiki.ubuntu.com/Python Python 2.7 and Python 3.2 only in Ubuntu 12.04. With Precise Pangolin, we have dropped Python 2.6.
21:52:10 [bitmap]
oh, I only checked mbsandbox-bitmap.error.log.52
21:52:27 [ianmcorvidae]
oh, the numbering ascends as you go *back* in time :)
21:53:08 [bitmap]
of course…why would anyone think otherwise :P
21:53:16 [ianmcorvidae]
haha
21:53:27 [ianmcorvidae]
I guess I'm more used to how logrotate works than the average person, yes :P
21:56:08 [zas]
python 2.6 is safer, since some 'old' distribs are still using it, but i guess most are moving to 2.7 or even 3.x
21:56:10 [Freso]
Jozo: *shrugs*
21:56:33 [Freso]
Jozo nikki zas: I was actually thinking about this last night.
21:56:47 [zas]
unittest module v2.7 has nice features
21:57:11 [Freso]
Jozo nikki zas: If I was the Picard lead, I'd release 1.2 with Py2.6 compat., and then announce that 1.3+ would require Py2.7.
21:57:50 [Freso]
(I'd say there's enough new stuff in the repos now to warrent a 1.2 release, so that could be done as soon as someone bothers to make one.)
21:58:12 [zas]
Who's Picard lead ? ;)
21:58:21 [Freso]
No one, apparently. :)
21:58:43 [zas]
unittest.addCleanup() is new in 2.7 ...
21:58:56 [bitmap]
ianmcorvidae: got it working, thanks!
21:59:36 [zas]
and what is required qt version for Picard ?
22:03:58 [nikki]
why me?
22:04:31 [zas]
https://github.com/ghewgill/pyqver
22:04:51 [zas]
nice tool, we should perhaps add it to tests
22:11:09 [Freso]
nikki: Because someone wrote something in dark blue, so I assumed it to be you, since it usually is. :p
22:12:50 [Freso]
nikki: http://imgur.com/fisdguJ
22:13:12 [Freso]
Actually...
22:14:52 [Freso]
nikki: Better: http://imgur.com/As0nEVE
22:15:10 [nikki]
tsk
22:15:23 [nikki]
* nikki is bright pink and you're all black :P
22:15:32 [Freso]
:p
22:16:17 [Freso]
I'd make the background of the terminal lighter, but... I like the dark background terminal. :|
22:26:53 [Leftmost]
Leftmost has joined #musicbrainz-devel
22:26:53 [Leftmost]
Leftmost has joined #musicbrainz-devel
22:28:19 [djce]
djce has joined #musicbrainz-devel
22:33:48 [zas]
interesting, Picard test_asf is failing with python 2.6.... UnicodeDecodeError: 'utf16' codec can't decode byte 0x61 in position 24928
22:46:34 [Freso]
ianmcorvidae: Anything I can do at this point to speed up the retirement of MBChatLogger? :)
23:06:51 [Ben\Sput]
Ben\Sput has joined #musicbrainz-devel
23:10:34 [dimonov]
dimonov has joined #musicbrainz-devel
23:11:25 [jdamcd]
jdamcd has joined #musicbrainz-devel
23:27:46 [demosdemon]
demosdemon has joined #musicbrainz-devel
23:40:40 [ianmcorvidae]
Freso: I'm not sure :P
23:41:06 [Freso]
Man.
23:53:19 [Freso]
Woo!
23:53:33 [Freso]
First review posted as a pull request on GitHub!
23:53:37 [Freso]
(For mb-server, that is.)
23:53:52 [Freso]
https://github.com/metabrainz/musicbrainz-server/pull/10 - gaze upon it in amazement and wonderness!
23:54:54 [sivoais]
sivoais has joined #musicbrainz-devel
23:56:02 [Freso]
(I assume metabrainz:beta is the proper branch to request the PR for, right?)
23:56:34 [bitmap]
we can use pull requests now? I thought the blog said no
23:57:36 [Ben\Sput]
\o/ http://pi.ockmore.net:19048/
23:58:05 [Freso]
bitmap: http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-21.html#T20-38-12-483563
23:59:21 [Freso]
My understanding of the outcome of tonight's meeting is that we're moving to use GitHub PR's for everything now and then review it for a last time at some point after the coming schema change.