IRC log of musicbrainz-devel on 2012-02-06
Timestamps are in UTC.
- 01:40:33 [kurtjx]
- kurtjx has joined #musicbrainz-devel
- 03:02:11 [kurtjx]
- kurtjx has joined #musicbrainz-devel
- 04:44:01 [ianmcorvidae]
- devs: release still planned for tomorrow? before or after meeting? :)
- 04:51:00 [reosarevok]
- What are you planning to get in it in the last moment?
- 04:52:39 [ianmcorvidae]
- well, I was vaguely thinking of working on the stats ocharles requested
- 04:52:44 [ianmcorvidae]
- they shouldn't be hard, so
- 04:55:50 [ruaok_]
- ruaok_ has joined #musicbrainz-devel
- 04:56:34 [reosarevok]
- ianmcorvidae, if they don't get into this they'll get into the next
- 04:56:41 [reosarevok]
- nothing is lost by doing them early :p
- 04:57:00 [ianmcorvidae]
- except the stats don't get collected for the intervening time :P
- 04:57:28 [ianmcorvidae]
- which doesn't matter unless you care about progression over time, of course, but still
- 04:57:42 [reosarevok]
- Sure
- 04:57:50 [ianmcorvidae]
- heh, two of the six tickets in the release thus far are already mine
- 04:57:56 [reosarevok]
- What I mean is: is there any reason *not* to start it already?
- 04:58:12 [ianmcorvidae]
- oh
- 04:58:18 [ianmcorvidae]
- just the other work I should be doing :P
- 04:59:10 [reosarevok]
- So, not really? :D
- 04:59:16 [ianmcorvidae]
- pretty much :P
- 04:59:24 [ianmcorvidae]
- heh, the six tickets are my two fixes, two thinks bitmap did (probably both for picard), the thing hrglgrmpf pestered rob to do the other day, and one thing ocharles did
- 04:59:29 [ianmcorvidae]
- things*
- 04:59:51 [ianmcorvidae]
- I suspect there are more that just aren't officially assigned to the proper milestone, though :P
- 05:00:42 [reosarevok]
- I certainly hope so
- 06:20:38 [bitmap]
- surprisingly, the MBS tickets I had weren't Picard-related, just porting a feature from a userscript :)
- 06:20:46 [ianmcorvidae]
- hah
- 06:20:55 [ianmcorvidae]
- I guess that makes sense too
- 06:39:53 [andreypopp]
- andreypopp has joined #musicbrainz-devel
- 07:03:50 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 07:34:14 [ijabz]
- ijabz has joined #musicbrainz-devel
- 07:35:47 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 07:50:09 [andreypopp]
- andreypopp has left #musicbrainz-devel
- 08:07:47 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 08:17:23 [ijabz]
- ijabz has joined #musicbrainz-devel
- 08:27:12 [ijabz]
- ijabz has joined #musicbrainz-devel
- 08:40:01 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 09:12:01 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 09:44:02 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 09:45:00 [ianmcorvidae]
- * ianmcorvidae discovers http://open-advice.org/ (with chapter by our very own ruaok :D)
- 09:49:35 [hrglgrmpf]
- hrglgrmpf has joined #musicbrainz-devel
- 10:16:16 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 10:42:34 [reosarevok]
- reosarevok has joined #musicbrainz-devel
- 11:19:55 [ocharles]
- mornin'
- 11:22:53 [reosarevok]
- Hi ocharles
- 11:23:05 [ianmcorvidae]
- moin
- 11:24:58 [nikki]
- so what counts as critical in jira?
- 11:25:11 [ianmcorvidae]
- I was wondering that :P
- 11:25:16 [ianmcorvidae]
- * ianmcorvidae finally added jira's RSS feed
- 11:25:25 [nikki]
- ah, so you saw the same ticket as me :P
- 11:25:36 [reosarevok]
- heh
- 11:26:42 [ianmcorvidae]
- heh
- 11:26:45 [nikki]
- I was thinking major for that ticket, because the release editor shows you exactly what you're going to submit (so while it's really stupid, if you actually submit such crap, that's entirely your own fault) and you can work around it by doing the changes separately
- 11:29:06 [reosarevok]
- Huh, I have never had problems adding tracks in the middle of a release
- 11:29:18 [reosarevok]
- Although I guess that can happen if you use the parser, huh
- 11:29:21 [nikki]
- I don't think he did
- 11:29:32 [nikki]
- you just have to change a recording to use a new recording
- 11:33:12 [nikki]
- his ticket descriptions are also very helpful
- 11:33:33 [ocharles]
- oh, valeriy is rnrarchivist?
- 11:33:44 [nikki]
- looks lik it
- 11:33:45 [nikki]
- +e
- 11:34:11 [ocharles]
- * ocharles closes "critical" bug and goes to take a shower
- 11:34:16 [ocharles]
- (the tab that is :P)
- 11:34:58 [ianmcorvidae]
- ianmcorvidae has joined #musicbrainz-devel
- 11:34:58 [hrglgrmpf]
- hrglgrmpf has joined #musicbrainz-devel
- 11:53:25 [kurtjx]
- kurtjx has joined #musicbrainz-devel
- 12:25:43 [MBJenkins]
- Project musicbrainz-server_master build #89: ABORTED in 14 min: http://ci.musicbrainz.org/job/musicbrainz-server_master/89/
- 12:25:47 [MBJenkins]
- * oliver.g.charles: Add some MusicBrainz specific Plack debug panels
- 12:25:48 [MBJenkins]
- * oliver.g.charles: Move Static::Simple to Plack; only enable debug panels in debug mode
- 12:25:48 [MBJenkins]
- * oliver.g.charles: Replace musicbrainz_server.pl to use plackup
- 12:25:49 [MBJenkins]
- * oliver.g.charles: Update HACKING
- 12:25:49 [MBJenkins]
- * oliver.g.charles: Add Plack dependencies to the Makefile
- 12:25:50 [MBJenkins]
- * oliver.g.charles: Add Plack::Middleware::Debug and Statistics::Basic dependencies
- 12:25:50 [MBJenkins]
- * oliver.g.charles: Move musicbrainz_server.psgi to app.psgi, which is more idiomatic
- 12:25:51 [MBJenkins]
- * oliver.g.charles: Use namespace::autoclean in data modules
- 12:25:51 [MBJenkins]
- * oliver.g.charles: Remove Template Toolkit stderr debugging, now that this is in a Plack debug panel
- 12:25:52 [MBJenkins]
- * oliver.g.charles: Unfuck namespace::autoclean stuff
- 12:25:52 [MBJenkins]
- * oliver.g.charles: Use Plack FastCGI settings
- 12:25:53 [MBJenkins]
- * oliver.g.charles: Upgrade to Catalyst::Runtime 5.9
- 12:25:53 [MBJenkins]
- * oliver.g.charles: Carton fixes
- 12:25:54 [MBJenkins]
- * oliver.g.charles: Remove debugging information
- 12:25:54 [MBJenkins]
- * oliver.g.charles: Remove more debug code
- 12:25:55 [MBJenkins]
- * oliver.g.charles: Rewriting service runner to use carton/plackup
- 12:25:55 [MBJenkins]
- * oliver.g.charles: Upgrade File::ShareDir to 1.03
- 12:25:56 [MBJenkins]
- * oliver.g.charles: Remove tabs from nginx file
- 12:26:05 [nikki]
- if that doesn't get ollie's attention, nothing will :P
- 12:28:05 [reosarevok]
- Well, it doesn't say ocharles!
- 12:28:30 [ocharles]
- I cancelled it :)
- 12:28:45 [ocharles]
- I might turn the changelog off
- 12:28:50 [ocharles]
- seems to just be noise
- 12:51:31 [ijabz]
- ijabz has joined #musicbrainz-devel
- 12:55:17 [ianmcorvidae]
- ocharles, warp, ijabz, someone else who knows: want to update http://wiki.musicbrainz.org/MusicBrainz_XML_Meta_Data to be NGS
- 12:55:20 [ianmcorvidae]
- ?
- 12:56:29 [ijabz]
- Yes agreed this should be NGS
- 13:04:27 [MBJenkins]
- Project musicbrainz-server_master build #90: FAILURE in 18 min: http://ci.musicbrainz.org/job/musicbrainz-server_master/90/
- 13:04:33 [ocharles]
- hurrah
- 13:04:40 [ocharles]
- selenium again
- 13:05:27 [reosarevok]
- Quick poll
- 13:05:44 [reosarevok]
- http://wiki.musicbrainz.org/MusicBrainz_Tag - redirect to http://wiki.musicbrainz.org/MusicBrainz_Picard/Tags/Mapping ?
- 13:06:13 [ocharles]
- probably one for ijabz
- 13:08:05 [ijabz]
- I think thats out of date as well, I always consider https://docs.google.com/spreadsheet/ccc?key=0AoYQhIuWC-gcdHZwUDM3RGhneGMxSXpEX3pONXd6MWc&hl=en_US#gid=0 the master
- 13:08:22 [ijabz]
- but I don't know know how that fits into your wii model reosarevok
- 13:08:43 [reosarevok]
- Well, it's good to have at least one page with it
- 13:08:44 [ocharles]
- that's an interesting typo
- 13:08:48 [reosarevok]
- But two seems like overdoing it
- 13:09:18 [ianmcorvidae]
- the google doc and picard's tag mapping page probably need merging
- 13:09:24 [ianmcorvidae]
- I didn't know of the existence of the google doc
- 13:10:14 [ijabz]
- The google doc is much easier to mamge than the wiki, and is also used by the various taggers to try an achieve a semblance of uniformity
- 13:10:49 [ianmcorvidae]
- well, the information should be on the wiki so it can be in wikidocs
- 13:13:36 [nikki]
- who can actually edit the google doc?
- 13:15:09 [ijabz]
- me, luis, outside context, magictagger admin, voiceinsideyou, just have to ask I think, outsidecontext is owner
- 13:16:41 [kepstin-laptop]
- kepstin-laptop has left #musicbrainz-devel
- 13:19:41 [reosarevok]
- So, everyone agrees to redirect http://wiki.musicbrainz.org/MusicBrainz_Tag at least, right?
- 13:19:55 [ianmcorvidae]
- at least for now, I think
- 13:20:06 [ianmcorvidae]
- that page is hopelessly out of date, the Picard Tag Mapping page is at least more up to date
- 13:20:30 [reosarevok]
- Done
- 13:20:56 [ianmcorvidae]
- I think ideally we create a non-picard-specific tag page eventually that integrates the google doc information
- 13:21:15 [ianmcorvidae]
- for now we can at least supersede clearly incorrect information :)
- 13:21:44 [ianmcorvidae]
- related: I updated the developer section of http://wiki.musicbrainz.org/MusicBrainz_Documentation -- anyone have comments?
- 13:21:58 [ianmcorvidae]
- (literally everything in there was out of date; now only [[MusicBrainz Database]] is :P)
- 13:26:27 [voiceinsideyou]
- voiceinsideyou has joined #musicbrainz-devel
- 13:59:16 [warp]
- hello!
- 14:04:47 [kurtjx]
- kurtjx has joined #musicbrainz-devel
- 14:20:04 [reosarevok]
- Hi warp
- 14:21:40 [ocharles]
- gmornin
- 14:33:52 [MBJenkins]
- Project musicbrainz-server_master build #91: STILL FAILING in 17 min: http://ci.musicbrainz.org/job/musicbrainz-server_master/91/
- 14:33:52 [MBJenkins]
- warp: MBS-3590, make sure the session store and the wizard are using Cache::Memcached::Fast.
- 14:58:28 [MBJenkins]
- Project musicbrainz-server_master build #92: STILL FAILING in 16 min: http://ci.musicbrainz.org/job/musicbrainz-server_master/92/
- 14:58:28 [MBJenkins]
- * warp: MBS-4210, provide an easy way to switch between production and staging robots.txt files.
- 14:58:29 [MBJenkins]
- * warp: Remove remaining tabs from nginx file.
- 14:59:07 [warp]
- * warp looks at the failing build.
- 14:59:17 [ocharles]
- it's selenium
- 15:09:43 [kepstin-netbook]
- kepstin-netbook has joined #musicbrainz-devel
- 15:14:53 [reosarevok]
- reosarevok has changed the topic to: Agenda: reviews, relating to works (ocharles/reosarevok/nikki)
- 15:27:33 [voiceinsideyou]
- voiceinsideyou has joined #musicbrainz-devel
- 15:30:10 [warp]
- ocharles: INSTALL still has "carton exec ./script/musicbrainz_server.pl -- -r" even though that script was removed from that branch. (master)
- 15:32:34 [ocharles]
- ops
- 15:32:54 [ocharles]
- I looked in HACKING for that
- 15:33:45 [ocharles]
- "carton exec -- plackup -Ilib -r" should do the job
- 15:35:25 [warp]
- _I_ know how to run it with plackup, I'm just pointing out that INSTALL needs to be updated :)
- 15:36:13 [ocharles]
- ok, just making sure you didn't spot that because you wanted to know how to run it
- 15:36:16 [ocharles]
- i've pushed an update out now
- 15:40:40 [ruaok]
- ruaok has joined #musicbrainz-devel
- 15:40:51 [kepstin-netbook]
- kepstin-netbook has joined #musicbrainz-devel
- 15:53:52 [MBJenkins]
- Project musicbrainz-server_master build #93: STILL FAILING in 17 min: http://ci.musicbrainz.org/job/musicbrainz-server_master/93/
- 15:53:53 [MBJenkins]
- * oliver.g.charles: Do not run asynchronous tagging code if there is no user logged in
- 15:53:53 [MBJenkins]
- * oliver.g.charles: Fix Plack debug stuff with the search DAO
- 15:53:54 [MBJenkins]
- * oliver.g.charles: Fix a possible warning in the release editor
- 15:53:54 [MBJenkins]
- * oliver.g.charles: Fix a warning view 'create work' edits which have no work type
- 15:53:55 [MBJenkins]
- * oliver.g.charles: Fix INSTALL to correctly mention plackup
- 15:59:10 [wpl]
- wpl has joined #musicbrainz-devel
- 16:20:33 [hawke_]
- hawke_ has joined #musicbrainz-devel
- 16:20:38 [kurtjx]
- kurtjx has joined #musicbrainz-devel
- 16:20:51 [kepstin-netbook]
- kepstin-netbook has joined #musicbrainz-devel
- 16:23:13 [ocharles]
- ocharles has changed the topic to: Agenda: reviews, relating to works (ocharles/reosarevok/nikki), decision required tickets
- 16:32:01 [ocharles]
- warp: we are meant to release today, when is good for that?
- 16:33:17 [warp]
- ocharles: hrm.
- 16:33:35 [warp]
- ocharles: we just merged a bunch of stuff into master.
- 16:34:08 [warp]
- if we release that today, that means most of that hasn't been tested on beta.
- 16:34:18 [warp]
- warp has changed the topic to: Agenda: reviews, relating to works (ocharles/reosarevok/nikki), decision required tickets, beta workflow
- 16:34:20 [reosarevok]
- nikki, go edit a lot!
- 16:34:25 [ocharles]
- not personally hugely bothered about that, because beta isn't defined yet
- 16:34:57 [reosarevok]
- Well, it's defined as "a place to find what breaks before we find out the hard way"
- 16:35:02 [reosarevok]
- That as much we know :p
- 16:35:05 [warp]
- ocharles: I am bothered by beta not being defined yet :)
- 16:35:17 [warp]
- warp has changed the topic to: Agenda: reviews, relating to works (ocharles/reosarevok/nikki), decision required tickets, beta workflow (warp)
- 16:35:36 [warp]
- warp has changed the topic to: Agenda: reviews, relating to works (ocharles/reosarevok/nikki), decision required tickets (ocharles), beta workflow (warp)
- 16:35:39 [ocharles]
- we might need to adopt http://nvie.com/posts/a-successful-git-branching-model/ in full if we want to avoid having these days
- 16:35:42 [ocharles]
- delays*
- 16:35:51 [warp]
- delays?
- 16:36:19 [ocharles]
- well merging to master means they aren't going to be sufficiently beta tested
- 16:36:29 [ocharles]
- so it either delays the release, or means they don't get beta tested
- 16:36:31 [warp]
- ocharles: to clarify, I'm also not hugely bothered by releasing the stuff in master now. I'm only bothered by beta not being defined yet.
- 16:36:48 [reosarevok]
- ocharles: it doesn't need to do either, if stuff is merged earlier
- 16:37:14 [ocharles]
- reosarevok: that doesn't answer the question of me submitting a review yesterday, and merging it this morning
- 16:37:24 [ocharles]
- warp: ok, that's fine :)
- 16:37:27 [reosarevok]
- Maybe it just needs to decide that anything finished less than n days before release day has to wait until the next one
- 16:37:37 [reosarevok]
- And get tested in the meantime
- 16:37:39 [ocharles]
- reosarevok: sure, but that needs a different branching model
- 16:37:52 [ocharles]
- that's what made me think about git-flow above
- 16:38:05 [reosarevok]
- Why? Wouldn't it just need to wait until post-release to be merged into beta?
- 16:38:21 [ocharles]
- * ocharles doesn't really want to go into discussing beta now
- 16:38:30 [reosarevok]
- It would also make sense to use beta post-release that way (right now it's useless until a few days pass and new stuff gets finished)
- 16:38:32 [ocharles]
- someone just needs to write something up
- 16:38:33 [warp]
- ocharles: oh, btw, I cannot reproduce the jenkins selenium failures in the browser.
- 16:38:38 [ocharles]
- warp: joy :(
- 16:39:05 [warp]
- ocharles: IMO that's good news. whatever they're testing works fine, so it won't block the release.
- 16:39:24 [ocharles]
- * ocharles nods
- 16:39:37 [warp]
- it just means the selenium part of our testing infrastructure is broken. which is nothing new.
- 16:40:13 [warp]
- ocharles: I notice plackup runs at :5000 now.
- 16:40:27 [ocharles]
- ya
- 16:41:21 [warp]
- I thought that was perhaps affecting the tests on my machine, but it really shouldn't. (I changed the references in the selenium tests from :3000 to :5000)
- 16:44:19 [warp]
- ocharles: anyway, I'm ready to release whenever you are. There are two tasks which need to be performed on production for this release:
- 16:44:46 [warp]
- 1. update DBDefs.pm with correct settings for Session::Store::Memcached
- 16:45:14 [warp]
- 2. ln -s root/robots.txt.production root/robots.txt
- 16:45:18 [ocharles]
- 3. Update the service/run script to use the new plackup one
- 16:45:23 [ocharles]
- 4. Update Carton
- 16:45:32 [warp]
- ok :)
- 16:45:45 [ocharles]
- how shall we approach this?
- 16:45:59 [warp]
- you do all of that
- 16:46:03 [warp]
- and I just mess with carl.mb
- 16:46:04 [warp]
- :)
- 16:46:06 [ocharles]
- with the servers online or offline?
- 16:46:09 [ocharles]
- a carton install takes a while
- 16:46:24 [warp]
- right, but we have four servers in rotation now, right?
- 16:46:31 [ocharles]
- yea
- 16:47:04 [warp]
- or. well, I guess you can run the "carton install --deployment" step before taking a server offline.
- 16:47:15 [ocharles]
- that would mean having to do a git pull
- 16:47:27 [ocharles]
- which means the running code differs from the working copy, and that *might* cause buggy behavior
- 16:47:46 [warp]
- right, if we've changed the templates. because those are used from disk.
- 16:48:21 [ocharles]
- yea... sort of
- 16:48:27 [ocharles]
- i think the problem happens when a process restarts
- 16:48:42 [warp]
- oh right, we have that going on as well.
- 16:48:55 [warp]
- is ./local/ relocatable?
- 16:49:04 [ocharles]
- yea
- 16:49:15 [warp]
- can you do a seperate git clone, carton install, then mv local /home/mb/server ?
- 16:49:19 [ocharles]
- maybe it's best if I just do a separate clone, carton install --deployment, then move it over
- 16:49:21 [ocharles]
- heh
- 16:49:36 [warp]
- right. let's do that first then.
- 16:49:40 [warp]
- on all servers.
- 16:49:52 [ocharles]
- ok
- 16:49:57 [ocharles]
- i'll get to that and ping you when I'm done
- 16:50:08 [warp]
- great
- 16:55:08 [ianmcorvidae]
- local is relocatable, that's like 95% of how rika works, very convenient :D
- 16:55:20 [ianmcorvidae]
- not that the question wasn't already answered, but still :)
- 17:08:35 [the_metalgamer]
- the_metalgamer has joined #musicbrainz-devel
- 17:11:10 [ocharles]
- astro loses the race today!
- 17:19:16 [warp]
- :)
- 17:19:56 [ocharles]
- warp: ok, all servers have up to date deps
- 17:20:06 [ruaok]
- ruaok has joined #musicbrainz-devel
- 17:20:13 [warp]
- ocharles: the selenium testrunner isn't able to connect to Catalyst at all. could that be caused by the plack changes?
- 17:20:26 [ocharles]
- it's possible
- 17:20:32 [warp]
- ocharles: ok, let's do the release first.
- 17:20:33 [ocharles]
- do you have any diagnostics?
- 17:20:33 [ocharles]
- ok
- 17:20:42 [ocharles]
- * ocharles also has to do maths work 1830-2000
- 17:21:02 [warp]
- UTC, so in an hour, right?
- 17:21:06 [ocharles]
- yep
- 17:22:13 [warp]
- ok, I've taken asterix out.
- 17:22:38 [ocharles]
- ok, and for DBDefs, I need to consult defaults?
- 17:23:22 [warp]
- yes.
- 17:23:44 [warp]
- has the production servers been updated to use ianmcorvidae's memcached stuff?
- 17:23:49 [warp]
- s/has/have/
- 17:24:24 [warp]
- (I think we have two separate memcached servers for production, so it's not entirely applicable)
- 17:24:43 [ianmcorvidae]
- you'd need to not use MEMCACHED_SERVERS for the WIZARD_MEMCACHED entry, no
- 17:25:11 [ianmcorvidae]
- as far as I know it's just one for the wizard and one for everything else, though, so for the "everything else" you could still use it :)
- 17:25:23 [ocharles]
- hm
- 17:25:25 [warp]
- ianmcorvidae: both regular sessions and wizard sessions shouldn't be evicted. they can be on the same memcached server, but should be seperate from anything else.
- 17:25:26 [ocharles]
- we don't use a namespace, do we?
- 17:25:53 [ianmcorvidae]
- unless you changed DBDefs, you probably don't
- 17:25:57 [warp]
- ocharles: no, ianmcorvidae added that for rika so multiple servers using the same memcached don't clobber eachothers stuff.
- 17:26:10 [ianmcorvidae]
- pecastro asked for it ages ago too
- 17:26:20 [warp]
- * warp nods.
- 17:26:20 [ianmcorvidae]
- but I don't think production needs it
- 17:26:43 [ocharles]
- sub SESSION_STORE_ARGS
- 17:26:44 [ocharles]
- {
- 17:26:44 [ocharles]
- {
- 17:26:44 [ocharles]
- memcached_new_args => {
- 17:26:47 [ocharles]
- {
- 17:26:51 [ocharles]
- data => [ '10.1.1.15:1121' ],
- 17:26:54 [ocharles]
- namespace => '',
- 17:26:58 [ocharles]
- memcached_class => 'Cache::Memcached::Fast',
- 17:27:01 [ocharles]
- }
- 17:27:01 [ocharles]
- }
- 17:27:04 [ocharles]
- }
- 17:27:07 [ocharles]
- }
- 17:27:10 [ocharles]
-
- 17:27:14 [ocharles]
- correct?
- 17:27:19 [ianmcorvidae]
- 11211
- 17:27:21 [ocharles]
- that port is wrong
- 17:27:21 [ianmcorvidae]
- not 1121
- 17:27:24 [ocharles]
- i don't need to change wizard stuff, do I?
- 17:27:36 [warp]
- ocharles: probably not, no.
- 17:27:40 [ocharles]
- ianmcorvidae: I said that :)
- 17:27:46 [ocharles]
- ok
- 17:27:58 [ianmcorvidae]
- your message came in after mine; just figured I'd say what I saw :)
- 17:28:09 [ocharles]
- what about plugin_cache_options?
- 17:28:15 [ocharles]
- that stays the same?
- 17:28:19 [ocharles]
- (it's using ::fast)
- 17:28:32 [ocharles]
- this DBDefs is so nicely out of sync with defaults
- 17:29:24 [ocharles]
- compile resources can't connect to closure server :(
- 17:29:26 [warp]
- ocharles: er
- 17:29:45 [ocharles]
- FFS. why can't an update ever go right?
- 17:29:59 [ocharles]
- "Fail to connect to http://closure-compiler.appspot.com/compile:500 read timeout"
- 17:30:26 [warp]
- ocharles: PLUGIN_CACHE_OPTIONS should use a separate server, so not 10.1.1.15.
- 17:30:47 [ocharles]
- sub PLUGIN_CACHE_OPTIONS {
- 17:30:47 [ocharles]
- return {
- 17:30:47 [ocharles]
- class => "Cache::Memcached::Fast",
- 17:30:47 [ocharles]
- servers => ['10.1.1.15:11211'],
- 17:30:51 [ocharles]
- };
- 17:30:54 [ocharles]
- };
- 17:30:55 [ocharles]
-
- 17:30:58 [warp]
- hrm.
- 17:31:03 [ocharles]
- that's what it was before
- 17:31:06 [ocharles]
- (and is now)
- 17:31:07 [warp]
- what is the other server we're using?
- 17:31:15 [warp]
- which part is using that then?
- 17:31:16 [ocharles]
- I wonder if this is the problem :)
- 17:31:20 [ianmcorvidae]
- heh
- 17:31:29 [ocharles]
- one front end is talking to the wrong cache
- 17:31:51 [warp]
- ocharles: no, that's not the problem. the production session memcached has always had 'evicts: 0' when I checked.
- 17:32:02 [warp]
- oh
- 17:32:09 [ocharles]
- it matches astro
- 17:32:11 [warp]
- hehe, if they're different between front-ends, that IS a problem.
- 17:32:43 [ocharles]
- we use a different cache for objects, but otherwise everything else shares the session cache
- 17:33:27 [warp]
- ok, well, leave it like that then. it hasn't been a problem yet.
- 17:33:45 [ianmcorvidae]
- heh
- 17:33:49 [ocharles]
- i think I have it right...
- 17:35:38 [ocharles]
- ok, just cycling the server now
- 17:37:40 [ocharles]
- warp: ok, bring asterix back in
- 17:39:13 [warp]
- ok, asterix back in. pingu out. (gah, slow link).
- 17:39:33 [ocharles]
- release editor is crashing all over the place in asterix
- 17:39:48 [ocharles]
- well
- 17:39:52 [ocharles]
- one crash, a bunch of misses
- 17:40:33 [ocharles]
- onwards with the show..?
- 17:40:50 [warp]
- hm
- 17:40:54 [warp]
- yes!
- 17:41:34 [ruaok]
- * ruaok smiles
- 17:41:38 [ocharles]
- that's the 4th crash...
- 17:42:04 [ocharles]
- and there's the first bug report
- 17:42:07 [ocharles]
- (#musicbrainz)
- 17:42:10 [ianmcorvidae]
- heh
- 17:42:25 [warp]
- ocharles: I wonder if it's a problem with things being different between asterix and the other servers.
- 17:42:36 [ocharles]
- maybe
- 17:42:39 [warp]
- ocharles: Wizard.pm now uses Cache::Memcached::Fast on one of the servers but not the others.
- 17:43:06 [warp]
- oh, and the regular session store as well.
- 17:43:39 [warp]
- ocharles: make sure to keep backups of current production DBDefs.pm files before you make the neccesary changes :)
- 17:43:50 [ocharles]
- no backups
- 17:44:17 [warp]
- ocharles: you changed all of them already?
- 17:45:19 [ocharles]
- just asterix and pingu
- 17:45:22 [ocharles]
- i'll back up the others
- 17:45:30 [warp]
- ok
- 17:45:59 [ocharles]
- pingu is entirely unresponsive now
- 17:46:00 [ocharles]
- yay
- 17:46:06 [warp]
- fun.
- 17:46:46 [ruaok]
- even to pings?
- 17:46:50 [ocharles]
- pingu is back
- 17:47:01 [ocharles]
- ruaok: no, just it's normal inability to actually run a command
- 17:47:02 [ocharles]
- :)
- 17:47:07 [ruaok]
- ok
- 17:47:12 [ruaok]
- I wonder WTF that is all about.
- 17:49:45 [ocharles]
- warp: prod
- 17:50:16 [warp]
- ok
- 17:50:36 [warp]
- ocharles: pingu back, astroout.
- 17:50:39 [warp]
- astro out.
- 17:50:54 [ocharles]
- ianmcorvidae: has Translation.pm changed?
- 17:50:58 [ocharles]
- it's throwing loads of warnings :(
- 17:51:36 [ocharles]
- GET http://musicbrainz.org/ws/1/release/780271af-f0f3-4854-b750-5ad3ecbe08b5?type=xml&inc=tracks+release-events caused a warning: Use of uninitialized value $msgid in substitution (s///) at lib/MusicBrainz/Server/Translation.pm line 61.
- 17:51:37 [ocharles]
-
- 17:51:43 [ianmcorvidae]
- nikki's patch is in it
- 17:52:29 [ianmcorvidae]
- yeah, that's the one that makes extract_pot and our translation function work the same way
- 17:52:42 [ianmcorvidae]
- possibly needs an 'if $msgid;' tacked on the end
- 17:53:02 [ianmcorvidae]
- line is $msgid =~ s/\r*\n\s*/ /xmsg;
- 17:53:31 [ocharles]
- ok, well if someone could look into that, that'd be great
- 17:54:04 [warp]
- this is turning out be one of our best releases ever.
- 17:54:48 [ocharles]
- warp: SESSION_STORE_ARGS in DBDefs.default doesn't even look right
- 17:54:53 [ocharles]
- there is a hash in a hash
- 17:54:58 [ocharles]
- with no key
- 17:55:12 [warp]
- ocharles: yes, the hash in a hash is correct in the sense that when it's just a hash things break.
- 17:55:22 [warp]
- * warp tried to change it but didn't look into it further.
- 17:55:51 [ianmcorvidae]
- __PACKAGE__->config->{'Plugin::Session'} = &DBDefs::SESSION_STORE_ARGS;
- 17:56:07 [ianmcorvidae]
- it needs to be a hash in a hash anyway
- 17:56:34 [warp]
- I agree with ocharles that a hash in a hash doesn't make any sense.
- 17:57:07 [warp]
- I mean, not like this, when the inner hash is a key in the outher hash, probably with an undef value.
- 17:58:33 [ocharles]
- warp: astro back
- 17:58:54 [warp]
- ok, astro back. lolo out.
- 18:03:02 [ruaok]
- ruaok has changed the topic to: Agenda: reviews, relating to works (ocharles/reosarevok/nikki), decision required tickets (ocharles), beta workflow (warp), 3rd party site linking policy (ruaok)
- 18:04:28 [ocharles]
- warp: lolo back
- 18:04:45 [ocharles]
- but I don't think our servers are at all stable still
- 18:04:48 [warp]
- ok, lolo back.
- 18:04:53 [warp]
- * warp nods.
- 18:05:17 [warp]
- I'll try the release editor now.
- 18:05:39 [ocharles]
- mind you, I'm not seeing any errors in the filtered logs
- 18:05:56 [ocharles]
- cache miss
- 18:06:10 [reosarevok]
- reosarevok has changed the topic to: Agenda: reviews, beta workflow (warp), relating to works (ocharles/reosarevok/nikki), decision required tickets (ocharles), 3rd party site linking policy (ruaok)
- 18:06:37 [warp]
- the release editor is consistently crashing
- 18:09:05 [warp]
- ocharles: it doesn't seem to set a sessioncookie at all
- 18:09:17 [warp]
- so the session store is entirely broken with the current config
- 18:09:56 [ocharles]
- can't be entirely broken if you're logged in
- 18:10:23 [warp]
- just click "Merge release group" on any release group page.
- 18:10:25 [warp]
- nothing happens.
- 18:10:34 [ocharles]
- hm
- 18:10:41 [warp]
- being logged in is just through the remember me facility, that doesn't need a session.
- 18:11:03 [ocharles]
- that's true
- 18:11:22 [warp]
- ocharles: what do you suggest?
- 18:12:30 [ianmcorvidae]
- fixed the Translation.pm thing: http://codereview.musicbrainz.org/r/1766/
- 18:12:38 [ianmcorvidae]
- (not that it's pressing, but FYI)
- 18:13:15 [ocharles]
- warp: I have no idea :(
- 18:13:19 [ocharles]
- have you looked at dbdefs?
- 18:14:04 [warp]
- I'll take a quick look.
- 18:16:24 [ocharles]
- i'm sure that hash in a hash is not helping things
- 18:16:50 [ocharles]
- that's not what the docs say to do
- 18:17:04 [warp]
- right. but that's a working configuration on development.
- 18:17:28 [ocharles]
- paste your config
- 18:17:44 [ocharles]
- and take astro out a sec, I want to restart it with this config
- 18:18:11 [warp]
- sessions on beta also work.
- 18:18:42 [ocharles]
- beta doesn't have a hash in a hash
- 18:18:56 [warp]
- astro is out.
- 18:19:27 [warp]
- ah, indeed.
- 18:19:34 [ocharles]
- Caught exception in engine "Can't locate object method "forget_dead_hosts" via package "Cache::Memcached::Fast" at local/lib/perl5/Cache/Memcached/Managed.pm line 765."
- 18:20:03 [ocharles]
- that's a weird error
- 18:20:12 [ocharles]
- i think something hasn't shut down properly
- 18:20:33 [warp]
- memcached_new_args => {
- 18:20:33 [warp]
- {
- 18:20:33 [warp]
- data => MEMCACHED_SERVERS(),
- 18:20:33 [warp]
- namespace => MEMCACHED_NAMESPACE(),
- 18:20:33 [warp]
- memcached_class => 'Cache::Memcached::Fast',
- 18:20:35 [warp]
- }
- 18:20:37 [warp]
- }
- 18:20:40 [warp]
- is my local dev setup.
- 18:20:51 [ocharles]
- warp: are you sure astro is out?
- 18:21:04 [ocharles]
- seems odd that I'm getting periodic log messages
- 18:21:06 [warp]
- yes
- 18:22:39 [ocharles]
- not sure what to do about that above error
- 18:23:08 [ruaok]
- ocharles: remember the /doc is *always* being served by astro.
- 18:23:20 [ocharles]
- oh
- 18:23:26 [ocharles]
- even if it's out of rotation?
- 18:23:28 [ruaok]
- we haven't fixed that in any meaningful manner yet.
- 18:23:33 [ruaok]
- yes.
- 18:23:59 [ruaok]
- the transclusion table is the problem. it needs to live in a centralized location.
- 18:24:11 [warp]
- ocharles: what's your status? any progress with astro?
- 18:24:18 [ruaok]
- until it does, we will lose a few requests during an update.
- 18:24:37 [ocharles]
- no, I have no idea
- 18:24:47 [warp]
- ocharles: then we need to rollback.
- 18:25:07 [ocharles]
- it's just crashing on that exception I pasted above
- 18:25:23 [ocharles]
- give me another few minutes to prod things
- 18:25:45 [warp]
- ocharles: right, different version of Cache::Memcached::Managed and Cache::Memcached::Fast and such?
- 18:25:52 [warp]
- ocharles: what are the versions you have on astro?
- 18:25:59 [ocharles]
- I just checked against beta and they are the same
- 18:27:59 [warp]
- apparently it's a problem that Cache::Memcached::Fast doesn't have forget_dead_hosts, whereas Cache::Memcached does. but why is this not a problem on beta/development? so weird.
- 18:28:22 [ianmcorvidae]
- maybe it just hasn't ever needed to call it on beta/development
- 18:28:54 [warp]
- ianmcorvidae: sure, but why not, what's so different about production?
- 18:30:03 [ocharles]
- warp: I say we go back to Cache::Memcached as the class
- 18:30:07 [ocharles]
- rather that a full rollback
- 18:30:30 [warp]
- ocharles: ok, just for Session::Store::Memcached?
- 18:30:31 [ocharles]
- astro has that, and is now up
- 18:30:34 [ocharles]
- warp: yea
- 18:30:38 [warp]
- alright.
- 18:30:59 [warp]
- ocharles: astro back in, lolo out.
- 18:31:13 [ocharles]
- still happening
- 18:31:21 [ocharles]
- urgh, take astro back out
- 18:31:39 [warp]
- lolo back in, astroout.
- 18:32:19 [ocharles]
- having 4 cache settings is not helpful :)
- 18:32:30 [warp]
- :)
- 18:32:36 [kurtjx_]
- kurtjx_ has joined #musicbrainz-devel
- 18:32:59 [ocharles]
- ok, now astro should be ready
- 18:33:22 [warp]
- ocharles: astro back in, lolo out.
- 18:33:58 [ocharles]
- warp: lolo back
- 18:34:05 [Swarup]
- Swarup has joined #musicbrainz-devel
- 18:34:20 [warp]
- lolo back, pingu out.
- 18:34:38 [ruaok]
- brb
- 18:35:07 [ocharles]
- warp: pingu back
- 18:35:28 [warp]
- pingu back, asterix out.
- 18:35:47 [thresh]
- thresh has left #musicbrainz-devel
- 18:35:52 [ocharles]
- done
- 18:36:09 [warp]
- ok, all back.
- 18:36:11 [ianmcorvidae]
- difference with production is multiple processes connecting to memcached, I think; forget_dead_hosts is only called in a 'reset' function which in turn is only called in a '_check_socket' function which, if you're not in a different process, returns before calling reset
- 18:36:36 [ocharles]
- beta runs more than one process
- 18:36:58 [ocharles]
- (20)
- 18:37:18 [ianmcorvidae]
- hm
- 18:37:24 [warp]
- I'm still seeing release editor crashes.
- 18:38:21 [bitmap]
- bitmap has joined #musicbrainz-devel
- 18:39:11 [warp]
- yeah, I still don't get a sessionid.
- 18:39:52 [warp]
- ocharles: so, it's not working. I say rollback entirely.
- 18:40:37 [ocharles]
- merge works for me
- 18:40:55 [ocharles]
- meh, or not quite
- 18:41:05 [ocharles]
- * ocharles goes and turns the oven off
- 18:41:53 [ocharles]
- warp: go ahead
- 18:42:20 [warp]
- ok
- 18:42:34 [warp]
- asterix is out.
- 18:42:41 [ocharles]
- warp: btw, if we want session store to use ::Fast, why not use https://metacpan.org/module/Catalyst::Plugin::Session::Store::Memcached::Fast ?
- 18:42:50 [ianmcorvidae]
- ocharles: because our setup doesn't support it
- 18:42:58 [warp]
- I didn't know that existed.
- 18:43:07 [ianmcorvidae]
- we configure to config->{'Plugin::Session'}, that one wants config->{session}
- 18:43:10 [ianmcorvidae]
- * ianmcorvidae tried to use it on rika :)
- 18:43:40 [warp]
- ocharles: I'll look into using that soon then.
- 18:45:12 [Swarup]
- Hi ocharles..q) can replication script use a separate DBDefs.pm ..is there a way i can configure to use a different one than what MB Server uses..
- 18:45:27 [reosarevok]
- Swarup, they're trying to fix a mess :)
- 18:45:29 [reosarevok]
- Please wait a bit
- 18:45:57 [reosarevok]
- (unless ianmcorvidae can help?)
- 18:46:35 [Swarup]
- ok np thx
- 18:46:59 [ocharles]
- now compiling resources doesn't work
- 18:47:30 [warp]
- o_O
- 18:47:31 [ocharles]
- just leave asterix out and let me get this server working
- 18:48:09 [warp]
- you want to me take out another one?
- 18:48:17 [ocharles]
- no, just asterix
- 18:48:24 [warp]
- asterix is stillout.
- 18:48:43 [ocharles]
- ok
- 18:51:15 [ocharles]
- sessions on asterix are fine
- 18:51:27 [ocharles]
- that server isn't problematic, so that should be able to go back in rotation
- 18:51:34 [warp]
- ok
- 18:51:53 [warp]
- so I take out the next one?
- 18:51:55 [ocharles]
- yea
- 18:52:13 [warp]
- asterix back, pingu out.
- 18:53:03 [ocharles]
- sessions are fine on pingu too
- 18:53:34 [ocharles]
- try another server
- 18:54:22 [warp]
- ok, pingu back. astro out.
- 18:55:31 [ocharles]
- astro is behaving correctly as well
- 18:55:52 [warp]
- ok, astro back, lolo out.
- 18:56:26 [ocharles]
- yet musicbrainz.org consistents to not work
- 18:56:36 [ocharles]
- with 3 servers that do work when addresed by ip
- 18:57:50 [ocharles]
- pingu's DBDefs had namespace => '', and astro didn't have that option at all
- 18:57:53 [ocharles]
- that could be part of it
- 18:58:15 [warp]
- are they all consistent now?
- 18:58:31 [ocharles]
- i just changed astro and pingu, and they are now all the same
- 18:59:06 [ocharles]
- wait a minute
- 18:59:07 [warp]
- right, but musicbrainz.org is still broken despite that?
- 18:59:09 [ocharles]
- pingu is still wrong
- 18:59:16 [ocharles]
- that still has a double hash
- 18:59:20 [ocharles]
- so does asterix
- 18:59:38 [warp]
- confusing!
- 18:59:46 [ocharles]
- i am spending tomorrow sorting this config clusterfuck out and getting something versioned
- 18:59:51 [ruaok]
- ruaok has joined #musicbrainz-devel
- 18:59:53 [warp]
- lol
- 19:00:03 [ocharles]
- but for now, we need to restart all the servers again
- 19:00:12 [warp]
- ok, lolo is still out.
- 19:00:18 [ocharles]
- another pair of eyes on all these dbdefs would be very handy
- 19:00:29 [ruaok]
- I can help.
- 19:00:37 [ruaok]
- where should I look?
- 19:01:03 [ocharles]
- check all memcached related options on all servers
- 19:01:07 [ocharles]
- they should be the same
- 19:01:12 [ocharles]
- (as in same settings on all servers)
- 19:01:17 [ocharles]
- warp: lolo ready
- 19:01:34 [ruaok]
- why not pick on DBDefs file that is correct and then copy it to all the ohters?
- 19:01:48 [ocharles]
- because I don't trust them to all have exactly the same settings
- 19:01:55 [ocharles]
- i don't know if we configure them that way or not
- 19:02:04 [ruaok]
- we have in the past.
- 19:02:11 [adrianw]
- adrianw has joined #musicbrainz-devel
- 19:02:15 [ruaok]
- why would you not want them all to the same?
- 19:02:20 [warp]
- ocharles: lolo back, asterix out.
- 19:02:25 [ocharles]
- because our service run script is not all the same
- 19:02:46 [ocharles]
- warp: asterix back
- 19:02:50 [ruaok]
- I'm not suggesting that we copy those scripts.
- 19:02:54 [ruaok]
- just DBDefs.pm
- 19:02:58 [warp]
- ocharles: asterix back, pingu out.
- 19:03:03 [ocharles]
- ruaok: i know, but when some things are consistent and some things aren't, I lose track of what goes where
- 19:03:12 [ocharles]
- and we have some servers with symlinks to stuff, and some with copies
- 19:03:33 [ocharles]
- warp: pingu done
- 19:03:38 [warp]
- and we basically need to sort that all out and get it into a git repo :)
- 19:03:48 [ruaok]
- yeah.
- 19:03:52 [warp]
- ocharles: ping back, astro out.
- 19:04:02 [ocharles]
- lets see if it's behaving now
- 19:04:17 [ocharles]
- it looks like it is
- 19:04:55 [warp]
- yeah, this looks better.
- 19:05:02 [ocharles]
- astro back
- 19:05:17 [warp]
- ok
- 19:05:47 [warp]
- ocharles: so the release is done, but we're still on Cache::Memcached for the regular session store?
- 19:05:51 [ocharles]
- yea
- 19:05:53 [warp]
- ok
- 19:06:08 [ocharles]
- via ::Managed
- 19:06:14 [Swarup]
- Swarup has joined #musicbrainz-devel
- 19:06:18 [warp]
- I'll look into Catalyst::Plugin::Session::Store::Memcached::Fast today or tomorrow.
- 19:06:25 [ocharles]
- ok
- 19:06:42 [ocharles]
- i am now going to take a good break and be back for the meeting
- 19:07:01 [ocharles]
- but I only have an hour for that, cause I had to move my uni studies, so hopefully that doesn't overrun too :P
- 19:07:56 [warp]
- ocharles: bye! :)
- 19:08:06 [warp]
- * warp is going to take a lunch break now :)
- 19:09:01 [reosarevok]
- ruaok, maybe you can help Swarup?
- 19:09:13 [ruaok]
- Swarup: what's up?
- 19:09:32 [Swarup]
- Hi Rob..is it possible for LoadReplicationChanges to use a different DBDefs.pm instead of default one..
- 19:09:57 [ruaok]
- not easily.
- 19:10:01 [ruaok]
- what are you trying to do?
- 19:10:02 [Swarup]
- like is there a param that i can pass to point to a different one..
- 19:10:22 [ruaok]
- no
- 19:11:00 [Swarup]
- we've vips setup for db..so wanted MB Server to use that db vip but replication script use the master db..
- 19:11:39 [ruaok]
- I would check-out another codebase for that.
- 19:11:49 [ruaok]
- makes it explicit what is going on.
- 19:12:25 [Swarup]
- ha ok ..thx
- 19:32:06 [nikki]
- I just had two codebases when I wanted to do that too
- 19:33:49 [bitmap]
- bitmap has joined #musicbrainz-devel
- 19:43:18 [nikki]
- ruaok: the amazon images don't have info/buy links :P
- 19:43:42 [ruaok]
- oh jeez.
- 19:44:06 [ruaok]
- can you please add a task ticket to add those back in?
- 19:45:50 [jdamcd]
- jdamcd has joined #musicbrainz-devel
- 19:46:05 [ruaok]
- how the fuck are we earning amazon associate fees then?
- 19:46:14 [reosarevok]
- Magic
- 19:46:16 [nikki]
- the asin links
- 19:46:16 [ruaok]
- * ruaok doesn't understand the world.
- 19:46:33 [nikki]
- assuming we still are getting money from them
- 19:46:51 [nikki]
- http://tickets.musicbrainz.org/browse/MBS-4282
- 19:47:08 [ruaok]
- we are.
- 19:47:13 [ruaok]
- not much, but beer money. :)
- 19:47:22 [ruaok]
- it paid for out tower tavern tab. :)
- 19:47:37 [nikki]
- as much as we were pre-ngs?
- 19:48:09 [ruaok]
- yep.
- 19:48:23 [ruaok]
- hmm.
- 19:48:28 [ruaok]
- wait, let me check that.
- 19:49:26 [ruaok]
- its highly variable.
- 19:49:42 [ruaok]
- but even then it seems to be half of pre-NGS.
- 19:50:45 [nikki]
- the referrer stuff was missing for ages
- 19:51:22 [ruaok]
- not like it really matters that much.
- 19:51:30 [ruaok]
- the most we ever took in was $231 late 2010.
- 19:54:59 [ocharles]
- ruaok: I thought we couldn't get that money due to state laws?
- 19:55:25 [nikki]
- if you don't want the money, I'm sure reosarevok will happily take it :
- 19:55:26 [ruaok]
- yes, and for 3 months we didn't get ay.
- 19:55:26 [nikki]
- :P
- 19:55:28 [ruaok]
- any
- 19:55:45 [ruaok]
- then amazon and calfifornia struck some deal. and now monies are on again.
- 19:57:25 [ocharles]
- ah
- 19:58:19 [ocharles]
- where in the terms does it say we have to have to have the info/buy links btw?
- 19:58:24 [ocharles]
- * ocharles is looking at https://affiliate-program.amazon.com/gp/associates/help/operating/linking?ie=UTF8&pf_rd_t=501&ref_=amb_link_353005802_6&pf_rd_m=ATVPDKIKX0DER&pf_rd_p=&pf_rd_s=assoc-center-1&pf_rd_r=&pf_rd_i=assoc_operating
- 19:59:21 [ruaok]
- not sure.
- 19:59:29 [ruaok]
- is there a section on using their product images?
- 19:59:34 [ruaok]
- thats where the clause would be.
- 20:00:06 [ocharles]
- oh, this is for cover art
- 20:00:08 [ocharles]
- * ocharles tries to wake up
- 20:00:19 [ruaok]
- lol
- 20:00:21 [ruaok]
- <BANG>
- 20:00:23 [ruaok]
- meeting time!
- 20:00:35 [ruaok]
- long week, thats for sure.
- 20:00:50 [ruaok]
- I'll start.
- 20:00:54 [ijabz]
- ijabz has joined #musicbrainz-devel
- 20:01:02 [ruaok]
- since last week, I've traveled home.
- 20:01:07 [ruaok]
- and caught up on emails.
- 20:01:15 [ruaok]
- we've signed up a new customer for the live data feed.
- 20:01:19 [ruaok]
- which is exciting.
- 20:01:31 [ruaok]
- BUT, they need to remain anonymous for now.
- 20:01:40 [ruaok]
- because of their previous metadata provider.
- 20:02:21 [ruaok]
- other than that, I dont have much new. there is a lot of post-summit follow up that needs to happen, so I'm chewing through that right now.
- 20:02:25 [ruaok]
- ocharles: you next?
- 20:02:29 [ocharles]
- sure
- 20:02:31 [ocharles]
- not much from me
- 20:02:44 [ocharles]
- I was in London Monday - Thursday, so I only really hard Friday for MusicBrainz stuff
- 20:02:54 [ocharles]
- though monday and tuesday were musicbrainz related, but we covered that in the last meeting :)
- 20:03:00 [ruaok]
- * ruaok nods
- 20:03:14 [ocharles]
- as for friday... that was mainly just a catch up
- 20:03:23 [ocharles]
- 2 tickets closed, and I think stack traces should now be working on beta
- 20:03:45 [ruaok]
- oh, I looked at the DBDefs files for all 4 servers.
- 20:03:54 [ruaok]
- they are in /tmp on carl if you want to look.
- 20:04:00 [ruaok]
- they are all different.
- 20:04:09 [warp]
- yay
- 20:04:12 [ocharles]
- right
- 20:04:14 [ruaok]
- a lot of them still have RAWDATA DB endpoints defined.
- 20:04:16 [ocharles]
- i have access to DBDefs :)
- 20:04:31 [ruaok]
- ocharles: they are collected in one place, I mean.
- 20:04:35 [ocharles]
- * ocharles nods
- 20:04:43 [ocharles]
- that'll make diffing easier
- 20:05:04 [ruaok]
- in the past when we were setting up NGS, I was in the habit of making astro the master DBDefs.pm file.
- 20:05:15 [ruaok]
- and just splatting them across to the other server(s).
- 20:05:19 [ruaok]
- that worked fine.
- 20:05:22 [nikki]
- speaking of beta, the passwords appear to have been reset there
- 20:05:37 [ocharles]
- that would mean it's not using the live database
- 20:05:53 [warp]
- ugh
- 20:06:06 [warp]
- that's not good if it is poking the same memcached stores.
- 20:06:18 [ruaok]
- lets sort that after the meeting.
- 20:06:25 [warp]
- man our release processes are absolutely terrible :)
- 20:06:54 [ruaok]
- ok, onward.
- 20:06:59 [ruaok]
- warp, how about you?
- 20:07:53 [warp]
- I fairly standard week for me, mostly catching up on previous tickets in review which needed some work to be able to ship them.
- 20:08:25 [warp]
- one interesting discovery I made was that the release editor consistently crashes if the connection to memcached is lost.
- 20:08:44 [warp]
- I spent almost a day investigating and fixing that issue, which was supposed to release today.
- 20:09:01 [warp]
- but we hit some trouble when deploying it, so I need to look into that again.
- 20:09:51 [warp]
- also had some fun on hobbes, where I needed to restart nginx after making some changes
- 20:10:13 [warp]
- which then broke whole bunch of stuff. apparantly nginx hadn't been restarted in ages, and the config files in the meantime had changed underneath it.
- 20:10:20 [ocharles]
- heh
- 20:10:46 [warp]
- ruaok: that's it.
- 20:10:49 [ruaok]
- thx
- 20:11:07 [ruaok]
- warp, ocharles: did you two ever get added tot he access list at DWNI?
- 20:11:20 [ruaok]
- you two should clearly be able to reboot machines.
- 20:11:28 [warp]
- ruaok: I think I was added a very long time ago.
- 20:11:33 [ocharles]
- not sure I want that hat :)
- 20:11:41 [ruaok]
- it was quite dismayed to find out that mb was down for over an hour while I was in the air.
- 20:11:54 [ruaok]
- anyone know why we weren't able to respond faster than an hour?
- 20:12:31 [ruaok]
- hmm.
- 20:12:38 [warp]
- I'm not online all the time. I'd need to get a phone call or text message to be able to respond to such issues.
- 20:12:44 [ruaok]
- anyone have any suggestions on how we can handle this better in the future?
- 20:13:04 [ocharles]
- can we get automated texts?
- 20:13:08 [ijabz]
- * ijabz was not even aware it had happened
- 20:13:35 [ruaok]
- well, that is dicey.
- 20:13:42 [ruaok]
- sometimes we get false report of shit being down.
- 20:14:01 [ruaok]
- what we need is a place where we can stash info on how to contact someone to reboot a machine.
- 20:14:25 [ruaok]
- for instance, if someone notices MB is down and djce, ruaok, ocharles and warp are not online. then what?
- 20:14:31 [nikki]
- make a google document and share it with people who should know?
- 20:14:40 [ruaok]
- nikki: I was headed there. :)
- 20:14:42 [warp]
- key persons in this channel should have both my phone numbers.
- 20:14:52 [ruaok]
- yes, I'll make that happen.
- 20:14:53 [warp]
- but that's useless if they don't use them :)
- 20:15:09 [ruaok]
- ocharles: I'm going to add you to the ACL list so you can call in a reboot.
- 20:15:16 [ruaok]
- ok, onward then.
- 20:15:22 [ruaok]
- who else for review?
- 20:15:25 [ocharles]
- ok, you'll have to tell me what that actually involves
- 20:15:28 [ruaok]
- ianmcorvidae, nikki,ijabz?
- 20:15:28 [ijabz]
- me
- 20:15:32 [ijabz]
- So I the reworked basic search, now matches extra fields and misspellings and Im happy with the results and scores
- 20:15:41 [ruaok]
- ocharles: not much. pick up phone, tell em to reboot a server.
- 20:15:42 [ruaok]
- cake, really.
- 20:15:47 [ijabz]
- i.e http://test.musicbrainz.org/search?query=picies&type=artist
- 20:16:01 [ijabz]
- The only problem is that on hobbes it seems a bit slow, not how sure slow it would be on live, but trying to find ways to speed it up
- 20:16:57 [ijabz]
- Also did some other stuff http://tickets.musicbrainz.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SEARCH+AND+fixVersion+%3D+%22next+version%22+ORDER+BY+updated+DESC%2C+priority+DESC%2C+created+ASC&mode=hide
- 20:17:21 [ruaok]
- I think its a proxy issue.
- 20:17:42 [ruaok]
- hobbes is not slow, but requests can take eons to get out.
- 20:17:46 [ruaok]
- no idea what causes that.
- 20:18:25 [ruaok]
- ijabz: does that mean we have a search server release comig?
- 20:18:28 [ruaok]
- +n
- 20:18:32 [ijabz]
- I mean when you do a search its get abandoned if it takes more than 5 seconds
- 20:18:34 [ijabz]
- but Im away next week, so guess will be a couple of weeks before ready for a release
- 20:18:42 [ruaok]
- ijabz: ok.
- 20:18:47 [ruaok]
- ping me when you're back.
- 20:19:01 [ruaok]
- anyone else for review?
- 20:19:25 [ruaok]
- ok, onward. warp: beta!
- 20:19:38 [ruaok]
- ruaok has changed the topic to: agenda: beta workflow (warp), relating to works (ocharles/reosarevok/nikki), decision required tickets (ocharles), 3rd party site linking policy (ruaok)
- 20:19:58 [warp]
- ok!
- 20:20:00 [reosarevok]
- reosarevok has changed the topic to: agenda: beta workflow (warp), relating to works (ocharles/reosarevok/nikki), decision required tickets (ocharles), 3rd party site linking policy (ruaok), proposal system (reosarevok)
- 20:20:29 [warp]
- we need to settle on a workflow for beta, because currently we're barely using it
- 20:20:55 [ruaok]
- add to that, that nikki will soon be moving to a role of tester.
- 20:21:03 [ruaok]
- as reosarevok takes on being style leader.
- 20:21:16 [ruaok]
- so, this process ought to also include nikki.
- 20:21:54 [warp]
- and I think we really need it.
- 20:23:04 [reosarevok]
- I'd suggest beta being "frozen" a few days before release
- 20:23:14 [ocharles]
- I think we keep looking at beta the wrong way round
- 20:23:14 [reosarevok]
- (i.e. stuff being fixed but no new things being added)
- 20:23:24 [ocharles]
- instead of use designing a beta workflow, nikki et all should tell us how the expect to work
- 20:24:02 [warp]
- reosarevok: a week?
- 20:24:14 [reosarevok]
- Releases are every two weeks?
- 20:24:19 [reosarevok]
- (ideally)
- 20:24:25 [nikki]
- my main argument for beta was to give people chance to test things in a real editing environment, so what reosarevok said makes sense
- 20:25:24 [reosarevok]
- If every two weeks, maybe 5 days is a good amount of time
- 20:27:16 [ruaok]
- ok, now what?
- 20:27:36 [ruaok]
- we can't realistically solve this in the context of this meeting.
- 20:28:20 [ruaok]
- we need to pick a next step and I'll steal from djce's playbook: what are we trying to accomplish and how do we measure our success?
- 20:28:32 [ruaok]
- who would like to take a stab at defining those two?
- 20:28:33 [ocharles]
- * ocharles nods
- 20:28:43 [ocharles]
- i think someone using it is the best person to do that
- 20:28:57 [ocharles]
- i'll just end up coming up with something that's convenient for me, but not necessarily workable
- 20:28:59 [ruaok]
- nikki, can you take a look at that?
- 20:29:03 [warp]
- ocharles: haha
- 20:29:07 [nikki]
- ok
- 20:29:11 [ruaok]
- I think you're the most affected person.
- 20:29:15 [ruaok]
- ok, thanks.
- 20:29:26 [ruaok]
- shall we discuss that in a week and decide the next step?
- 20:29:31 [nikki]
- ok
- 20:29:44 [ruaok]
- which will likely be warp or ocharles proposing a process that meets your criteria.
- 20:29:50 [ruaok]
- right then.
- 20:29:57 [ruaok]
- relating to works.
- 20:30:11 [ruaok]
- who of reosarevok, ocharles and nikki wants to take the lead on this?
- 20:30:30 [warp]
- warp has changed the topic to: agenda: relating to works (ocharles/reosarevok/nikki), decision required tickets (ocharles), 3rd party site linking policy (ruaok), proposal system (reosarevok)
- 20:30:39 [reosarevok]
- Sounds like nikki's thing IMO
- 20:30:41 [reosarevok]
- Oh, wait
- 20:30:45 [nikki]
- I can explain the problem from the user's pov
- 20:30:46 [reosarevok]
- You mean relating to works
- 20:30:47 [ocharles]
- I'm generally struggling on this due to the size of it, but not sure what to really discuss
- 20:30:56 [ocharles]
- i understand the problem
- 20:30:59 [reosarevok]
- I thought you meant the previous thing (too many stuff going on)
- 20:31:09 [ocharles]
- i just am struggling to reach an end
- 20:31:25 [ruaok]
- ocharles: is the goal clear?
- 20:31:38 [ocharles]
- mostly due to me just not being an interface designer, and also struggling to separate the interaction from the rest of the code and having to work both in tandem
- 20:31:44 [ocharles]
- ruaok: the very high level goal is, sure
- 20:31:58 [ocharles]
- as a user, I want to be able to relate works to recordings, and artists to works and recordings, on a single page
- 20:32:02 [ocharles]
- that's my understanding
- 20:32:07 [ruaok]
- ocharles: is this the sort of thing where cooperating with navap might help?
- 20:32:20 [reosarevok]
- ocharles: that's indeed the very high level goal
- 20:32:56 [reosarevok]
- ocharles: on a lower goal, doing it in two or even three different pages wouldn't be too big a problem if getting a single page for it is
- 20:32:58 [ocharles]
- ruaok: possibly, im pretty much at a loss on how to make good progress on this :(
- 20:33:09 [nikki]
- reosarevok: agreed
- 20:33:14 [ruaok]
- ocharles: then engage navap, please.
- 20:33:14 [ocharles]
- every time I feel like I make progress I run into something and it just stops
- 20:33:24 [ocharles]
- alright
- 20:33:32 [reosarevok]
- (as in: anything that lets users relate all recordings to works, and anything that lets users relate stuff to said works, would be a massive improvement)
- 20:33:37 [ruaok]
- this is one of his tasks. start a conversation and see if the two of you can break the stalemate
- 20:33:40 [reosarevok]
- (even if it's patchy at first)
- 20:33:46 [nikki]
- but ollie didn't want to do that because he wanted it to be part of his relationship editor, then all progress completely stopped :(
- 20:34:04 [ocharles]
- that stopped because i just don't feel I can deliver something stable
- 20:34:20 [ocharles]
- there's just too many moving parts to coordinate
- 20:34:38 [nikki]
- so why not go back to the original idea?
- 20:34:39 [ocharles]
- the main problem I hit this time was restoring the interface after a submission with errors, without throwing away partial changes
- 20:35:14 [ocharles]
- nikki: the original idea only shows how to relate works to recordings it seems, not the more important task of artists to works
- 20:35:20 [reosarevok]
- Why not just coordinate it one by one though? Make a "recordings to works" screen first
- 20:35:29 [reosarevok]
- Then you can do one for the artists to works
- 20:35:43 [ruaok]
- does a centralized AR editor even make sense?
- 20:35:45 [reosarevok]
- And then at a future point all of that can be made into parts of the relationship editor
- 20:35:49 [reosarevok]
- If we do it
- 20:35:59 [ijabz]
- Maybe better to spend the time adding this to editable web service, then let third parties develop suitable interfaces
- 20:36:11 [ocharles]
- ijabz: I thought about that during a walk earlier
- 20:36:18 [nikki]
- ruaok: I think so, people have been asking for the ability to add relationships in the release editor for years
- 20:36:27 [nikki]
- (this isn't in the release editor, but the idea is similar)
- 20:36:30 [ruaok]
- nikki: ok
- 20:36:34 [ocharles]
- yea, I do think it makes sense=
- 20:36:41 [reosarevok]
- ruaok, sense, yes. urgency, not so much
- 20:36:44 [ocharles]
- we just don't have the infrastructure code wise to achieve it
- 20:36:54 [ruaok]
- ocharles: what are we missing?
- 20:36:55 [ocharles]
- ie, client/server rendering split problem, amongst others
- 20:37:19 [ocharles]
- ruaok: there is no clear responsibility on who is responsible for rendering things, and who's responsible for validation
- 20:37:35 [ocharles]
- and who's responsible for relaying failed validation to the client
- 20:37:41 [ocharles]
- which is mostly what warp is working to fix :)
- 20:37:42 [ruaok]
- maybe you and warp ought to make a plan for that.
- 20:38:00 [ruaok]
- given that we're changing models with the RE improvements he is working on.
- 20:38:12 [warp]
- yes, review my MBS-211 branch!
- 20:38:21 [ocharles]
- warp: we should talk about that tomorrow
- 20:38:24 [ocharles]
- warp: I haven't been ignoring it :)
- 20:38:29 [warp]
- ocharles: ok :)
- 20:38:41 [ruaok]
- ok, sounds like we have some next steps to pursue.
- 20:39:00 [ruaok]
- hopefully you two can come up with the next steps past that.
- 20:39:03 [ocharles]
- just to summarise...
- 20:39:17 [ocharles]
- talk to navap and try and get some more interaction clarified
- 20:39:24 [ocharles]
- possibly proceed with separate pages for now to get something done
- 20:39:35 [ocharles]
- talk with warp about how this fits in with an editable web service
- 20:39:40 [ocharles]
- did I miss anything?
- 20:39:44 [ruaok]
- sounds good.
- 20:39:49 [ijabz]
- One more thing I forgot earlier , warp tried to use my 'all search', I was expecting it to be used like discogs search, show top artists, releases, labels but warp was looking at more like a google search combined list which is much harder
- 20:39:49 [reosarevok]
- Sounds fine
- 20:40:30 [ruaok]
- ijabz: sounds like our goals for the combined search are not clear.
- 20:40:41 [warp]
- * warp nods.
- 20:40:42 [ruaok]
- * ruaok sounds like a skipping CD.
- 20:40:45 [warp]
- lol
- 20:40:56 [ruaok]
- ijabz: maybe post to mb-devel and see what sorts of feedback we can get on what people do want?
- 20:41:10 [warp]
- mb-user would be a better place
- 20:41:15 [ruaok]
- sure.
- 20:41:26 [warp]
- we don't particularly care what developers want. we want to know what users want. :)
- 20:41:28 [ruaok]
- ok, lets move on. decision required tickets, ocharles !
- 20:41:34 [ijabz]
- yes, that was suggested.
- 20:41:41 [warp]
- warp has changed the topic to: agenda: decision required tickets (ocharles), 3rd party site linking policy (ruaok), proposal system (reosarevok)
- 20:41:52 [ocharles]
- ok, in my "within 3 months" milestone, I have a lot of stuff decision required
- 20:41:54 [ruaok]
- warp: then why did we listen to you in the first place? :) :)
- 20:41:57 [ocharles]
- yes, it's this problem again :)
- 20:42:37 [ruaok]
- are they issues where someone wants something and its not clear what to do?
- 20:42:48 [ruaok]
- those cases are easy in my opinion.
- 20:43:03 [ruaok]
- tell the requester to work to solve the issue and remove it from the 3 mo bucket.
- 20:43:13 [ocharles]
- http://tickets.musicbrainz.org/browse/MBS-4133 and http://tickets.musicbrainz.org/browse/MBS-4071 are assigned to me
- 20:43:22 [warp]
- decision required IMO is simple. whoever reported a bug has the responsibility to get feedback from stakeholders and make the decision or to make sure the decision is made.
- 20:43:43 [ocharles]
- but there are 3 more in that milestone that need a decision (and are unassigned)
- 20:43:51 [reosarevok]
- ocharles, links please :)
- 20:44:09 [ocharles]
- http://tickets.musicbrainz.org/browse/MBS-1935 http://tickets.musicbrainz.org/browse/MBS-3204 and http://tickets.musicbrainz.org/browse/MBS-1989
- 20:44:23 [ocharles]
- combined with the 2 above make up the blockers for 3mo
- 20:44:28 [ruaok]
- ocharles: so its more about specific tickets than it is the process of dec required?
- 20:44:49 [ocharles]
- perhaps (: i just want to move these tickets along
- 20:45:05 [ocharles]
- also, we need to fill 3mo more, but I guess that'll come when we start scheduling again
- 20:45:09 [ruaok]
- ocharles: then you're on the right track. add each ticket to the agenda.
- 20:45:24 [ruaok]
- maybe not do them all at once, but maybe have one or two tickets per meeting?
- 20:45:30 [ruaok]
- lets tackle the first two tickets.
- 20:45:31 [ocharles]
- alright
- 20:45:34 [ruaok]
- 4133 and 4071.
- 20:45:37 [warp]
- ok, that sounds like a plan.
- 20:45:41 [ruaok]
- we'll leave the others for next week.
- 20:46:00 [ocharles]
- for 4133, see my last comment
- 20:46:08 [ruaok]
- moving to moose sounds like a pita.
- 20:46:15 [ruaok]
- do you know if moose 2 is faster?
- 20:46:25 [ocharles]
- no, but it's supported
- 20:46:32 [ocharles]
- we're 2 years out of date now
- 20:46:40 [ruaok]
- ah, ok.
- 20:46:48 [ruaok]
- sounds like this is clear: we need to move ahead.
- 20:46:51 [ocharles]
- +1
- 20:46:54 [ruaok]
- so update carton and fix the tests.
- 20:47:01 [ocharles]
- "fixing" the tests is not easy
- 20:47:04 [ruaok]
- (the ones that break post moose 2)
- 20:47:06 [ocharles]
- that's why we haven't done this before
- 20:47:07 [ruaok]
- tedious?
- 20:47:09 [warp]
- I'm happy with getting rid of the memory cycle tests, considering we have a "solution" and we're not going to spend any more time on that anyway.
- 20:47:14 [ocharles]
- no, I don't know how to fix them
- 20:47:28 [ocharles]
- they fail because a cycle gets created "somewhere", which I think is some sort of moose optimization
- 20:47:30 [ruaok]
- ocharles: you ok with nuking the tests as suggested by warp?
- 20:47:33 [ocharles]
- yea
- 20:47:38 [ruaok]
- ok, motion carried.
- 20:47:45 [ocharles]
- ok :)
- 20:47:46 [warp]
- yay!
- 20:47:48 [ruaok]
- then dump the tests and see about getting mose upgraded.
- 20:47:50 [ruaok]
- +o
- 20:47:54 [ruaok]
- 4071
- 20:48:06 [ruaok]
- gah.
- 20:48:09 [ruaok]
- this ticket wont die.
- 20:48:29 [ruaok]
- djce did a package for the BBC.
- 20:48:38 [ruaok]
- that never made it to CPAN, did it?
- 20:48:46 [ruaok]
- * ruaok notes djce is out til wed
- 20:48:52 [ocharles]
- i don't think so
- 20:49:01 [ocharles]
- i looked into doing this myself, but I think it means I have to learn XS
- 20:49:18 [ruaok]
- can you please assign the ticket to djce and ask what the status of the BBC stuff is?
- 20:49:22 [ocharles]
- ok
- 20:49:36 [ruaok]
- if that is a viable candidate, then I can help with motivating the BBC to toss this over the fence.
- 20:49:46 [ruaok]
- I'd hate to duplicate work.
- 20:50:01 [ruaok]
- ok, onward then.
- 20:50:04 [warp]
- warp has changed the topic to: agenda: 3rd party site linking policy (ruaok), proposal system (reosarevok)
- 20:50:18 [ruaok]
- I hinted at this topic at the summit, but it was out of the scope of the meeting.
- 20:50:45 [ruaok]
- lets say that company X comes to us and says: We have a shitload of pages that are MBID addressable.
- 20:50:50 [ruaok]
- we'd like to have MB link to our pages.
- 20:51:05 [ruaok]
- some will say: all ids resolve (last.fm)
- 20:51:19 [ruaok]
- some will say, not all ids resolve (SU, artistxite)
- 20:51:25 [reosarevok]
- If all IDs resolve, I'd say auto-link merrily
- 20:51:29 [ruaok]
- the former is easier.
- 20:51:35 [ruaok]
- the latter is harder.
- 20:51:45 [ruaok]
- how should we proceed to get community feedback on this?
- 20:51:49 [ocharles]
- is it possible to ask these people to provide us with a daily dump of mbids they do have?
- 20:51:49 [ruaok]
- post to style?
- 20:51:51 [ruaok]
- blog post?
- 20:51:57 [ruaok]
- daily??
- 20:52:11 [ocharles]
- however often they want us to update stuff
- 20:52:13 [ruaok]
- ocharles: what is your goal with that?
- 20:52:21 [ruaok]
- to do manual linking?
- 20:52:22 [ocharles]
- to stop pointing to 404s
- 20:52:24 [reosarevok]
- Show only ones that resolve
- 20:52:30 [ocharles]
- no, but to know what will resolve and what won't
- 20:52:43 [ruaok]
- right.
- 20:52:47 [reosarevok]
- Makes sense
- 20:52:48 [ruaok]
- what do we do with that info?
- 20:53:10 [ocharles]
- stick it in a per-customer table or tables, and we can add some logic on our side
- 20:53:13 [warp]
- not display links which don't go anywhere.
- 20:53:15 [ruaok]
- I'm guessing that we're never going to want to add a pile of links automatically.
- 20:53:29 [ruaok]
- or do we?
- 20:53:39 [ocharles]
- i don't think these belong in ARs
- 20:53:42 [ruaok]
- again, this discussion is too big to settle in the context of this meeting.
- 20:53:47 [reosarevok]
- ruaok, I'm perfectly happy adding those as long as they a) resolve and b) are separated from user links
- 20:53:49 [warp]
- if a site talks MBIDs, I'm happy with show an automatic link _IF_ the link goes somewhere.
- 20:53:53 [ruaok]
- how and where should this discussion happen?
- 20:53:55 [reosarevok]
- I don't think this is a style decision
- 20:53:56 [warp]
- s/show/showing/
- 20:54:01 [reosarevok]
- I think this is a MeB decision, tbh
- 20:54:11 [ruaok]
- reosarevok: no, its not.
- 20:54:21 [ruaok]
- I keep getting complaints about how decisions are being made in MB.
- 20:54:25 [nikki]
- this is where murdos's idea of a community board thingy would be helpful :P
- 20:54:31 [ruaok]
- and having Meb decide this is only going to make this worse.
- 20:54:35 [warp]
- it's a style decision whether the link in itself is useful. it's an #mb-devel decision on how to implement the link.
- 20:54:39 [ocharles]
- it's less a board thing, more an issue of no dedicated channel for talk like this
- 20:54:51 [reosarevok]
- It's a different thing for each one :D
- 20:54:54 [ruaok]
- ocharles: +1
- 20:54:54 [ocharles]
- it's not a ticket, so it's not jira, but we have a ML/forum split - and it should be one of them
- 20:55:09 [reosarevok]
- ruaok covers his ears and shouts
- 20:55:24 [reosarevok]
- :p
- 20:55:27 [ocharles]
- warp: I don't think it's style, because it's not our data
- 20:55:34 [warp]
- new relationships (including URL relationships) have always been discussed on mb-style, I have no problem with this custom.
- 20:55:36 [ruaok]
- there are two things to be worked out: first the process. second actual instances.
- 20:55:52 [reosarevok]
- warp: this is not a relationship inasmuch as the users can't add them or remove them
- 20:56:01 [ruaok]
- ok, I see no consensus forming.
- 20:56:17 [reosarevok]
- I mean, you want me to bring it to style? I will
- 20:56:19 [warp]
- reosarevok: I know that, but that's a technical issue. it shouldn't really matter to style _how_ something is related to an URL, just that it is or isn't.
- 20:56:28 [ruaok]
- should I: post a blog entry, post to mb-devel, users, style?
- 20:56:31 [reosarevok]
- I just don't see the need, but I can do it
- 20:56:46 [nikki]
- make a poll, post it in various places, if the community votes to add it to the site, add it :P
- 20:56:55 [ruaok]
- warp: lets ignore the technical aspects for now.
- 20:57:01 [ruaok]
- lets deal with the process first.
- 20:57:09 [reosarevok]
- That doesn't fix the problem of cases where it's required for an agreement
- 20:57:15 [reosarevok]
- (say, SU)
- 20:57:22 [ruaok]
- then once we have an idea what we want to to, then we can figure out the technical issues.
- 20:57:33 [warp]
- ruaok: IMO the process for adding links, whether URL relationships or automatically generated, is mb-style.
- 20:57:46 [ruaok]
- reosarevok: that is fixed, since I am not going to enter into a contract with a linking requirement anymoe.
- 20:57:52 [reosarevok]
- Ok
- 20:57:59 [reosarevok]
- In that case, as I said
- 20:58:13 [ruaok]
- ok.
- 20:58:14 [nikki]
- warp: it's only one step away from ui decisions though, and they definitely don't belong on mb-style
- 20:58:16 [reosarevok]
- I can make it go through style
- 20:58:22 [ocharles]
- warp: I still think style is for our database and data that we currate
- 20:58:27 [ruaok]
- reosarevok: please bring the process part of this to style.
- 20:58:29 [ocharles]
- and this doesn't fit into that
- 20:58:52 [ruaok]
- ocharles: I somewhat agree, but I've gotten hammered on not bringning things to style.
- 20:58:54 [reosarevok]
- I still don't think it's a style issue, but I will see what style things of that maybe :p
- 20:59:06 [ruaok]
- so lets start there and if it really dopesn't belong there, we'll find a new home.
- 20:59:07 [warp]
- ocharles: IMO mb-style in this way curates links to other databases
- 20:59:28 [ruaok]
- reosarevok: ask me if you have questions about the process nature of this.
- 20:59:34 [ruaok]
- thats it on this topic.
- 20:59:40 [ruaok]
- reosarevok: proposal system.
- 20:59:43 [nikki]
- ruaok: I thought the objection was that the community didn't get their say, not that it didn't specifically go through style
- 20:59:55 [reosarevok]
- ruaok: if you want an artistxite (or similar) link to actually make it through style I'll need you to tell me how you see it benefitting MB
- 20:59:55 [ruaok]
- nikki: I've gotten hammered on both points. :)
- 20:59:58 [warp]
- warp has changed the topic to: agenda: proposal system (reosarevok)
- 21:00:01 [reosarevok]
- (last.fm I can defend myself)
- 21:00:11 [ruaok]
- reosarevok: its not about artistxite yet.
- 21:00:33 [ruaok]
- its about how to make these decisions. lets leave any concrete examples out until we have a process in place.
- 21:00:41 [reosarevok]
- Well, if you ask a group of decision-loving people whether they want to take decisions, they're going to say yes :p
- 21:00:43 [ruaok]
- once we have that we can push cases through.
- 21:00:49 [reosarevok]
- Anyway, proposal system
- 21:01:00 [reosarevok]
- the current proposal system is a bit of a mess
- 21:01:20 [reosarevok]
- So nikki and I were talking of streamlining it a bit, getting rid of that huge Proposals page and tracking stuff in Jira instead
- 21:01:34 [reosarevok]
- http://wiki.musicbrainz.org/User:Reosarevok/Proposals is what I have right now - it's not ready to go live yet
- 21:01:55 [reosarevok]
- I want anyone who can to poke holes in it, say where it doesn't look like it would work, etc
- 21:02:11 [reosarevok]
- (just drop any comments in the talk page)
- 21:02:17 [warp]
- reosarevok: ok
- 21:02:19 [ruaok]
- * ruaok will read the page.
- 21:02:27 [ruaok]
- reosarevok: done?
- 21:02:33 [reosarevok]
- It does have at least an unclear case we know of
- 21:02:37 [reosarevok]
- Counter-proposals
- 21:02:51 [reosarevok]
- Not that those have ever actually been used well now
- 21:03:03 [nikki]
- they've never been used :P
- 21:03:09 [reosarevok]
- But still, it makes sense so tips for how to track those in Jira would be nice
- 21:03:11 [ruaok]
- then do we need to address them?
- 21:03:17 [reosarevok]
- Well
- 21:03:25 [ruaok]
- track them as related tickets?
- 21:03:34 [ruaok]
- in general +1 to using jira for this.
- 21:03:49 [ijabz]
- reosarevok: I like the jira idea
- 21:03:50 [reosarevok]
- Being able to tell someone who says "I don't like your proposal" "The rules say you must give what *you* want for it" would help to keep stuff moving
- 21:03:59 [nikki]
- ruaok: I don't like the idea of separate tickets because they're two solutions to the same proposal
- 21:04:16 [reosarevok]
- If it is "stay like now", nothing is needed
- 21:04:33 [nikki]
- so by definition one would be wontfix and the other would pass
- 21:04:38 [reosarevok]
- But for cases like "We need a guideline for this but I'll block yours and not propose anything better" (which do happen) it'd help
- 21:04:54 [ruaok]
- I think having counter proposals in the same ticket would get confusing.
- 21:05:05 [reosarevok]
- Sub-tasks are also an option
- 21:05:08 [ruaok]
- well, we're in overtime.
- 21:05:12 [warp]
- reosarevok: there are many cases where the alternate proposal would be "keep the status quo". so I'm not happy with requiring a counter proposal.
- 21:05:13 [reosarevok]
- Although technically they aren't sub-tasks either
- 21:05:21 [ruaok]
- lets leave comments in the wiki page regarding counter terrorism proposals.
- 21:05:22 [reosarevok]
- warp: that *is* a counterproposal
- 21:05:28 [reosarevok]
- "I don't like it" is not
- 21:05:41 [warp]
- reosarevok: I don't really see the distinction.
- 21:06:07 [ruaok]
- ok, time to wrap up.
- 21:06:10 [ruaok]
- thanks everyone!
- 21:06:12 [ruaok]
- </BANG>
- 21:06:12 [MBChatLogger]
- MBChatLogger has changed the topic to: http://musicbrainz.org/#devel
- 21:06:14 [reosarevok]
- "I don't like it because what we have now is better, because of this and this" vs. "I don't like this" (without saying anything about how to proceed)
- 21:06:14 [warp]
- thank you ruaok!
- 21:06:31 [ocharles]
- right, on to the joys of sequences and MST121!
- 21:06:44 [reosarevok]
- And also "I don't like it, this is broken, fix it" vs. "I don't like it, I think doing it like this and this and this would work"
- 21:06:45 [warp]
- reosarevok: "I don't like it, but I don't know have a better solution to the problem"
- 21:07:02 [reosarevok]
- If there's a problem, why would you keep the status quo?
- 21:07:11 [warp]
- reosarevok: IMO "I don't like it, this is broken, fix it" is a perfectly valid response.
- 21:07:24 [nikki]
- ruaok: btw, the idea is only to track the status, not for discussion. a comment saying "foo created counter-proposal bar" doesn't seem confusing to me
- 21:07:33 [warp]
- reosarevok: because the solution offered doesn't improve things enough.
- 21:07:48 [reosarevok]
- So a half-fix is worse than nothing?
- 21:07:57 [ruaok]
- nikki: ok, that makes more sense. but I can see people discussing there anyway.
- 21:08:02 [reosarevok]
- In a few cases maybe, but...
- 21:08:13 [warp]
- reosarevok: if I believe a better solution is possible, yes. regardless of wether I am able to offer such a better solution.
- 21:08:13 [reosarevok]
- ruaok, any discussion in jira will be cut by swift removal of comments :p
- 21:08:14 [nikki]
- ruaok: we've considered closing comments or deleting them if people keep doing that
- 21:08:39 [ruaok]
- I;m ok with that. :)
- 21:08:40 [reosarevok]
- heh
- 21:08:45 [ruaok]
- go read the rules! :)
- 21:09:09 [reosarevok]
- warp, ideally that's OK - in practice, it means the wrong status quo is likely to stay in place with no other solution
- 21:09:22 [ruaok]
- " The RFC period only defines the minimum time for debate, not a maximum." LOL
- 21:09:28 [reosarevok]
- If everything had to be perfect from the beginning we wouldn't have MB
- 21:09:28 [reosarevok]
- :p
- 21:09:32 [ruaok]
- is that a good idea? should we set some sort of maximum?
- 21:10:22 [reosarevok]
- Well, that's there from the current system
- 21:10:30 [nikki]
- and we know who wrote that :P
- 21:10:43 [ruaok]
- * ruaok notes that RFC and RFV are never defined.
- 21:10:46 [reosarevok]
- It's more meant to be a "we can discuss until no further useful discussion is happening"
- 21:10:47 [ijabz]
- warp, I'm going to leave posting to mb-users about search all because how the user actually sees the results is more your side of things
- 21:10:51 [ruaok]
- RFV == request for veto, right? :)
- 21:11:06 [reosarevok]
- ruaok, except in the DEFINITIONS part at the top, they're not :p
- 21:11:11 [nikki]
- hahaha
- 21:11:20 [ijabz]
- sorry i meant, leave it to you
- 21:11:27 [nikki]
- reosarevok: we don't seem to have defined what happens once someone has a counter-proposal btw
- 21:11:28 [ruaok]
- * ruaok looks sheepishly at the top
- 21:11:41 [kurtjx]
- kurtjx has joined #musicbrainz-devel
- 21:12:01 [reosarevok]
- nikki, certainly, because we don't know :p
- 21:12:06 [warp]
- ijabz: ok
- 21:12:18 [reosarevok]
- Ideally, ruaok would have coded his voting-like thingy
- 21:12:30 [reosarevok]
- But he hasn't yet, so...
- 21:12:36 [nikki]
- well we can hold a vote on the mailing list if we have to
- 21:12:47 [nikki]
- that's how auto-editor elections used to be done :P
- 21:12:50 [ruaok]
- I'm going to set aside fridays as days for me to hack on such things.
- 21:12:58 [ruaok]
- since they are pretty quiet anyway.
- 21:14:11 [ruaok]
- does this new proposal still allow for the style person to override a veto?
- 21:14:19 [ruaok]
- I think that provision should be kept.
- 21:14:44 [reosarevok]
- Well, it does say vetos need to be clearly reasoned and not just "I don't like it"
- 21:14:57 [reosarevok]
- I don't think "style leader can block a veto" was actually *written* anywhere
- 21:15:00 [ruaok]
- even a well reasoned veto can hold up the process.
- 21:15:17 [ruaok]
- and sometimes a veto needs to be overriden to make progress.
- 21:15:18 [nikki]
- it does say "If the list cannot reach consensus they will make a decision."
- 21:15:47 [ruaok]
- nikki: I would make it more explicit.
- 21:16:35 [ruaok]
- thats just about my only comment. +1 in general.
- 21:16:56 [reosarevok]
- So, move clearly from consensus as a goal to consensus as a desired but not strictly necessary outcome
- 21:17:11 [ruaok]
- yes
- 21:17:26 [reosarevok]
- Ok
- 21:17:27 [ruaok]
- it should clearly be used judiciously.
- 21:17:38 [ruaok]
- but it should be possible so that one person can't stonewall the process.
- 21:17:47 [reosarevok]
- Well, if I wanted to be a dictator I'd have written a dictatorial system :p
- 21:18:10 [ruaok]
- the style leader is a BDFL like position, keep that in mind. :)
- 21:18:28 [ruaok]
- they key is that those powers best never be used.
- 21:18:34 [ruaok]
- but they are still there for contingencies.
- 21:19:31 [reosarevok]
- Sure
- 21:19:31 [ruaok]
- * ruaok goes for fudz
- 21:19:41 [hawke_]
- reosarevok: I like the proposed proposal system. :-)
- 21:20:20 [hawke_]
- reosarevok: What about starting new RFCs/RFVs for the same item?
- 21:20:33 [reosarevok]
- In which way?
- 21:20:33 [hawke_]
- Should those be RFC-2 or 'second RFC' or ….?
- 21:20:36 [reosarevok]
- Oh
- 21:20:51 [reosarevok]
- I'd say RFC-2 or RFC v.2 or whatever
- 21:21:03 [reosarevok]
- Doesn't matter too much, as long as it's clear that it is an RFC, and the second
- 21:21:04 [nikki]
- * nikki thinks either work, as long as they make it clear it's an rfc and not just discussion
- 21:21:19 [hawke_]
- I don’t really like that distinction
- 21:21:58 [reosarevok]
- Well, discussion can just be "let's get something we can kinda agree on so I elaborate on it"
- 21:22:09 [reosarevok]
- RFC is "this is exactly what I'm proposing"
- 21:22:14 [hawke_]
- If there’s discussion, you’re asking for comments
- 21:22:29 [hawke_]
- Without just calling it an RFC, you get “pre-RFC” crap
- 21:22:30 [nikki]
- and we don't want rfvs just popping out of the middle of a discussion
- 21:22:33 [reosarevok]
- I mean discussion more as asking for ideas
- 21:22:47 [hawke_]
- Where someone has a proposal in mind, but it hasn’t been discussed on the list before
- 21:23:32 [reosarevok]
- Well, "pre-RFC", or nothing at all, implies "I want to move forward and write something specific for this. how do you think it should be done"
- 21:23:37 [warp]
- I think there is much value in discussing a particular problem before proposal a solution.
- 21:23:50 [reosarevok]
- RFC is "this is actually what I'm proposing and want us to do"
- 21:24:08 [reosarevok]
- Ideally, an RFC shouldn't change too much once it's ongoing
- 21:24:11 [nikki]
- warp: agreed
- 21:24:22 [hawke_]
- warp: I agree, but I don’t like the way having RFCs and RFVs encourages a sort of unofficial process prior to that…
- 21:24:23 [reosarevok]
- Some small fixes and clarifications, sure
- 21:24:28 [reosarevok]
- but the general idea should be the same
- 21:24:31 [reosarevok]
- Why?
- 21:24:46 [hawke_]
- because if there’s a process it should be official/documented
- 21:25:19 [nikki]
- * nikki suggests adding something to the 'preparation' section saying to discuss it on the list first then :P
- 21:25:19 [reosarevok]
- How would you document "hey, I think this is an issue, how do we solve it, any ideas?"
- 21:26:14 [nikki]
- I do think it'd make sense to recommend discussing things first, most of the proposals that pass easily are the ones which have already been discussed somewhere
- 21:26:28 [reosarevok]
- Oh
- 21:26:32 [reosarevok]
- I did think that was there
- 21:26:45 [reosarevok]
- I'll add it
- 21:29:12 [warp]
- hawke_: I see no need for a process before the RFC stage.
- 21:30:05 [warp]
- hawke_: if people discuss something and come up with a good solution on wednesday evening in the pub, that's great. the RFC stage seems the perfect point for the formal process to start.
- 21:30:12 [reosarevok]
- "It sometimes makes sense to discuss the idea a bit on the style mailing list before going forward, as it will help people show you issues with it that you should take into consideration to make your proposal more likely to pass. This is not required though; if you have a clear idea of how to solve what you want to solve you can always go on directly."
- 21:30:48 [hawke_]
- Agreed.
- 21:34:00 [reosarevok]
- So, is anyone against adding that to the docs?
- 21:34:11 [hawke_]
- I like it
- 21:35:31 [reosarevok]
- I know that :p
- 21:35:37 [reosarevok]
- I was more thinking about nikki and warp
- 21:36:13 [warp]
- * warp not.
- 21:36:17 [warp]
- I'm packing my stuff.
- 21:36:20 [warp]
- back tomorrow!
- 21:50:23 [hawke_]
- reosarevok: What about the RFC-numbering? gone completely?
- 21:54:02 [bitmap]
- bitmap has joined #musicbrainz-devel
- 22:02:10 [reosarevok]
- hawke_, ideally, yes
- 22:02:17 [reosarevok]
- Jira has its own numbering
- 22:02:19 [hawke_]
- yUP
- 22:02:23 [hawke_]
- I like that
- 22:02:33 [reosarevok]
- And it doesn't depend on people stepping on each other because they forgot to update it on the page
- 22:02:38 [hawke_]
- exactly
- 22:02:44 [ruaok]
- +1
- 22:06:04 [reosarevok]
- "If it becomes clear that a proposal which has general agreement will keep being held indefinitely by a single veto, the style leaders have the right to decide on the issue and override the veto. This power will be used as little as possible - consensus is the ideal goal of the style process."
- 22:06:32 [reosarevok]
- Does that sound natural and clear?
- 22:08:59 [ruaok]
- it does.
- 22:09:04 [ruaok]
- but I think its very narrowly drafted.
- 22:09:24 [ruaok]
- it limits your powers to that situation only.
- 22:12:04 [reosarevok]
- Well, if the proposal is not generally backed, why would I want to enforce it?
- 22:12:12 [reosarevok]
- That'd defeat the whole point of style...
- 22:13:28 [reosarevok]
- What other situations do you have in mind?
- 22:14:17 [ruaok]
- unforeseen situations. :)
- 22:14:28 [warp]
- a double veto.
- 22:14:46 [ruaok]
- how about "style leaders can use their powers for resolving issues in the RFC/RFV process"
- 22:16:25 [hawke_]
- If it’s supposed to be describing the power of the style leader, that seems circular.
- 22:16:40 [hawke_]
- style leaders have the power to use their powers? ;-)
- 22:17:03 [ruaok]
- you get me drift. :)
- 22:17:05 [ruaok]
- my
- 22:17:08 [reosarevok]
- Well, it says "If the list cannot reach consensus they will make a decision"
- 22:17:10 [reosarevok]
- In the definition
- 22:17:37 [reosarevok]
- I'd argue we could specify the most obvious reason, and then use the less specific wording to justify exceptional uses if needed
- 22:21:04 [reosarevok]
- Hmm
- 22:21:18 [reosarevok]
- Did JS break?
- 22:21:46 [reosarevok]
- JS cleanup for links seems not to work
- 22:21:49 [reosarevok]
- hawke_, can you try?
- 22:21:59 [hawke_]
- ?
- 22:22:54 [reosarevok]
- Try to add a discogs link to a release
- 22:23:02 [reosarevok]
- See if it gets auto-cleaned and "discogs" selected
- 22:23:25 [reosarevok]
- (you don't have to actually enter it, so pick any random release and http://www.discogs.com/Galaktlan-Laanetaguse-Suvi/release/486981 or whatever)
- 22:23:35 [hawke_]
- It does not.
- 22:25:14 [reosarevok]
- Meh
- 22:25:30 [reosarevok]
- warp, I won't be able to convince you to look into it today, right?
- 22:27:42 [reosarevok]
- We should have a recurrent ticket
- 22:27:47 [reosarevok]
- "JS is broken"
- 22:27:52 [reosarevok]
- So we can reopen it as needed
- 22:29:33 [reosarevok]
- warp / ocharles: http://tickets.musicbrainz.org/browse/MBS-4283
- 22:29:36 [reosarevok]
- There
- 22:30:45 [the_metalgamer]
- the_metalgamer has joined #musicbrainz-devel
- 22:53:28 [ocharles]
- if js is broken the release editor probably wouldn't work
- 22:53:32 [ocharles]
- does your console say anything?
- 22:53:44 [ocharles]
- and you can always reopen tickets
- 22:54:33 [reosarevok]
- * reosarevok checks
- 22:54:56 [reosarevok]
- heh... it works now...
- 22:55:03 [reosarevok]
- wtf
- 22:55:16 [reosarevok]
- Might it be that only one server is complaining?
- 22:56:14 [reosarevok]
- Dunno :/
- 23:01:38 [ocharles]
- possible
- 23:01:42 [ocharles]
- i'll regenerate them all now
- 23:03:10 [ocharles]
- has that made a difference?
- 23:04:47 [reosarevok]
- Works
- 23:04:51 [ocharles]
- cool
- 23:04:56 [ocharles]
- wanna close that ticket? :P
- 23:05:01 [reosarevok]
- Let's wait until the morning
- 23:05:05 [reosarevok]
- As I commented there
- 23:05:07 [ocharles]
- alright
- 23:05:17 [reosarevok]
- If nobody else complains / you see no problems when you're up, close it
- 23:16:53 [ocharles]
- btw, will be blogging this tomorrow too
- 23:17:20 [ocharles]
- just wanted to make sure we didn't have to rollback, and now I don't want to even type the blog address in, let alone type an intro :)
- 23:18:07 [reosarevok]
- Fine :)
- 23:21:43 [ocharles]
- nn
- 23:22:44 [ruaok]
- nn
- 23:25:06 [kepstin-netbook]
- kepstin-netbook has joined #musicbrainz-devel
- 23:46:56 [kurtjx]
- kurtjx has joined #musicbrainz-devel