#musicbrainz-devel

Should be a quick one anyway

but we'll see

ocharles: do you have stuff for review?

i can do a week review

please excuse typos, im on a very bizzare keyboard

for the start of my week i was working on a new project, musicbrainz-email

this is a separate service that listens on a message queue for email "requests" and then sends email

i wrote this for sending out password reset emails, but it grew quite a bit over the week. hopefully we can deploy that tonight

(ps. though I am hosting this meeting. I am currently is south america, where consumer internet connections are not very reliable. usually when the connection drops it reconnects in three minutes or so)

then midweek we had a big outage so i had to be around for that

it turns out our /browse pages absolutely hammer the database in terms of network traffic, and take half the site down

not fun

we flipped over to baron, so i had to spend a bunch of time reconfiguring slave replication

but thankfully we're past that now

is that ws/ browse?

i was motivated by all this to look into graphite and monitoring more, so we started to collect system stats via graphite

no, the main website

sadly, the graphite stuff runs on a vm that doesn't have good enough io performance in the current configuration, so i accidently took all our vms down

oops :)

along with that, the normal reviews

fin.

ok

I don't have much interesting to report either. I probably spent about a day on the fire fighting ocharles already mentioned.

some reviews, and the remaining time on making all the tests pass for the track identifier changes.

excellent

warp: do you have any notes on the track id changes/docs?

I also spent some free time trying to write a rate limiter in haskell. But I'm new to haskell, so obviously that's going to take a while.

(and that was my internet bugging out for a minute)

Ben\Sput: what kind of notes?

i was thinking it would be useful to give tagger people/luks a heads up as to how it will affect them

i think thats looking good though

so, how they'll be accessible, mainly

(since luks may need to change acoustid to use track ids before we bring in the updated recording guidelines)

Ben\Sput: no, I haven't properly considered the changes to the webservice yet. I first need to get all the tests to pass, then work on the UI changes.

Ben\Sput: I don't think luks had any intention to change that anyway :p

(ask him, but)

is their an sql migration script for schema changes, and is it basically finished ?

reosarevok: judging from style he does, but anyway, back to warp :)

ijabz: last SQL patch I plan to finish post-meeting

ijabz: the schema-changes-2013-05-15 branch contains (almost) all the changes.

(alastairp was very late so I took over)

Once that's done, I'm not sure how it goes :)

ijabz: including the upgrade script (upgrade.sh)

leftmost's work is also missing from that

(and I appreciate it, sorry - had a bunch of stuff come up, but it all finished today)

my cover art media-type is missing from it as well.

i'd really like to see everything missing merged this week

we're starting to run very fine - less than a month til testing

I'm kind of waiting for this before try to update searchserver

and I haven't even started on UI code yet :(

but let's continue reviews. anyone else for review? :)

i started some of my ui code today

(looks like a no)

Ben\Sput: relationships!

\o/

warp has changed the topic to: Yakutsk | http://musicbrainz.org/#devel | Agenda: Relationships (Ben), doc/Recording (Ben), multiple barcodes (ocharles)

so, I've been doing the rfc for the proposal for changing the recording style guidelines

and also another proposal on audiobook guidelines (which is abandoned now)

but in both cases, people have been saying they'd like relationships to be easier to use

and would also like more features, such as inheritance in relationships

i came up with the idea of being able to make arbitrary groups of relationships which could be copied onto entities

and i was wondering if anyone else had any thoughts on how we could make them easier to use?

there's a lot we can do with ui stuff without changing the data model

like that grouping

and i think we should look at all of that first

Having a tool to copy rels would be nice

It'd probably be good to have an option to clone all of the relationships from one entity to another

:P

Inheritance might be too, but it's more complex

(not only in code, also as a concept)

(since not everything should be inherited)

I think inheritance is definitely something we should look at in the future

but the main improvement i'd like to see is definitely cloning/sharing of relationships, which would make recordings so much easier to add/maintain

defining exactly how inheritance works would be a real pain

the cloning/sharing stuff does raise questions of data redundancy though

but that's all beyond the scope of this meeting

for inheritance, we either need an additive model with the ability to 'black out' relationships that don't apply, or an override model, which means having duplication :/

I don't see how inheritance could work properly without a schema cange.

Freso: it needs a schema change

it probably couldn't

A schema change and a shitton of work

it would be good then, if in the short term, someone could make a user script to copy relationships

inheritance sounds like a complete nightmare for everyone wanting to use the data :/

Yeah, there's that

it all sounds too vague to say anything meaninful at this stage

I'd like "inheritance" as in being able to add and remove and edit relationships for several related things at the same time

yeah, and that. we'd have to define the rules for how inheritance works so others can apply them - and probably have the webservice resolve the inheritance and show only the final relationships

I'd certainly want them to be stored separately though

Much easier to use

Ben\Sput: can you work with a few people to put together some more concrete proposals, and/or prototype with userscripts, etc.. ?

warp: I'll see what I can do :)

great :)

let's move on

Ben\Sput again! doc/Recording.

:)

... isn't this a style issue? not sure why it's in the dev meeting.

this is mainly me asking whether we want http://wiki.musicbrainz.org/User:LordSputnik/Pr... to replace doc/Recording

ie. http://wiki.musicbrainz.org/Recording

kepstin-work: no, style is wiki.musicbrainz.org/Style/* :)

the main change is to add a definition section to the top

the definitions themselves have been reviewed by style too, and they seem mostly happy with them at this point

(note: we'll also probably want to update http://wiki.musicbrainz.org/Mix_Terminology too)

I think we should probably replace the /doc/Recording page at the same time as the matching style guidelines are applied.

kepstin-work: yes, no problem with that

Ben\Sput: after a quick read now it looks fine to me.

what is the status of "the matching style guidelines" ?

we're close to agreeing on them

Yeah, they look surprisingly close to consensus

most of the issues that have been raised have been resolved

:)

It's in RFC state with just minor squabbling over exact terminology and wording

good

should be ready long before schema change

and then we have to wait for luks to do whatever he wants to do to ensure that acoustid isn't ruined :)

there's no real schema change-related stuff involved tho, is there?

kepstin-work: track ids

track identifiers are related, and some people want them before the new style guideline is in effect because with the new guideline many recordings will be merged.

hmm; I don't see how acoustids attached to track ids is that useful, given the recording merges that are done already and the relative inaccuracy of acoustids

since the guideline will be much more permissive with merging, it has the potential to cause AcoustID to be much less effective at identifying tracks, so track ids are needed for luks to update links to avoid that

(acoustids in general can't tell different tracks with the same recording apart anyways...)

but that's up to luks :)

luks has certainly implied that he wants to do that

here: http://musicbrainz.1054305.n4.nabble.com/Result...

even without acoustid for some people the recording identifiers will be less suitable for their use case if they're merged more than they are now.

so is this RFC is basically going to be on hold for application until after the schema change?

kepstin-work: that seems likely, yes.

kepstin-work: I'd like to get it voted on, then hold it until it's ready

Ben\Sput: makes sense to me.

ok, then I think we're done for now on this topic.

yup

ocharles: tell us about the barcodes!

warp has changed the topic to: Yakutsk | http://musicbrainz.org/#devel | Agenda: multiple barcodes (ocharles)

im a bit worried that these are late and that we've already announced that we're going to do them

so i wonder if we should pull the plug on them and push them til october, or if we think we can fit them in

I don't see the big problem tbh

ocharles: leftmost has said he won't be able to finish that work, yes.

what remaining work is involved?

Ben\Sput, all the UI

I think that judging by how non of the ui stuff is done, we shouldn't commit to more work

ocharles: I'd say just move to October

it's already way overdue, so I agree with moving to october

the schema change work isn't even done, Ben\Sput - let alone the ui stuff

ocharles: ah ok

ok, we'll do that

warp has changed the topic to: Yakutsk | http://musicbrainz.org/#devel | Agenda:

Not the best day for DRs I guess :)

alright, then we're done.