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