#musicbrainz-devel

In the web service, ratings are submitted on a scale of 0-100, but returned on a scale of 0-5. This seems a little odd, is it too late to do anything about this?

Was there supposed to be a release yesterday? Or was it postponed to today like the dev meeting?

luks, what would you do with non-english words that mean feat.?

Standardise to feat. in recordings and use the original on tracks?

Use feat. in both? Original in both?

asking the wrong person :)

I'd remove all feat. info

but generally I don't think that tracks and recordings should use different wording on purpose

if you have X english releases and one german, then use mit just for the german track

but it doesn't make any sense to me to change the recording to something that is not used on *any* of the linked tracks

adhawkins: postponed to today

adhawkins: as we have no ruaok

np, figured as much

breakfast!

lunch!

ocharles: I'd like to discuss MBS-3102, do you have some time today?

I do indeed

fire away :)

this is about the "change track artists" boolean of the "edit release artist" edit

we previously decided that it should be on by default, and that there shouldn't be an interface to turn it off.

right

however, even if you manually reset all the artists on the tracklist tab, they will still be changed --- because those changes will result in a no-op mediam edit.

so, I'm think I need to detect such a no-op medium edit (both when previewing and submitting edits) and clear the boolean in that situation.

however, currently the medium edit doesn't know this at the preview stage, because missing entities have not been resolved.

If I have "Foo" by "Bar", which has one track: "Pancakes!" by "Bar", if I change the release "Bar" to "Waffles", does the RE internally change "Pancakes!" to be by "Waffles" as well?

ocharles: yes.

so, if the user changed it back to "Bar", (grep { $_->{artist_credit} eq 'Bar'} $release_editor->tracks > 0) will be true?

ocharles: well, only for those tracklists loaded into a release. so not for releases with more than X discs.

ah

is that likely to be a problem?

maybe? :)

which is to rename them

well, I can imagine edge cases where the result will not be what an editor expects, but they're edge cases, not likely to occur often.

yes.

so, surely it just needs to do:

Edit::Release::EditArtist->create( rename_track_artists => (grep { $_->{artist_credit} == $release->artist_credit } == 0) )?

that condition might be wrong, but I'm mostly saying that I don't see how this needs to change any edits internals

I'm not sure I understand what you're saying :)

well carry on with explaining what you want to discuss

and we can come back to that

well, the solution I had in mind to solve the problem already seems bad, so let me start fresh by explaining the problem again :)

Imagine 2 disc release: release artist: Foo, artist on all tracks on disc 1: Foo, artist on all tracks on disc 2: Foo

I want to change the release artist from Foo to Bar, but not change the track artists on disc 2.

the release editor should make:

1. Edit Release Artist (with change track artists), Foo -> Bar

2. Edit Medium Edit for disc 2, change Bar back to Foo.

I think it's easier to enter Edit Release Artist *without* changing artists, and entering edit medium edits

that second edit is currently not entered by the release editor, because it is a no-op before the first edit is applied.

we want to see edits that make changes, not edits that revert them

yep

that's much more votable too

ocharles: right, so the 'with change track artists' boolean should be disabled based on some condition, or always disabled?

Well, the reason we bought it in, was because loading n tracklists was too much work

right.

so you need some way to tell the server that a tracklist was loaded, but a no-op edit was made on it, so the server won't attempt to change the artists on that tracklist when the edit is sumbitted?

well, the only way what me and kepstin-laptop suggest is to load all the tracklists

I'm afraid the edit preview / submit will choke on 180 disc releases.

we have so few of them though

but I guess at some point we have to address that problem

you should still be able to change the release artist of those boxes :)

I imagine if we've got as far as 180 discs, the release artist is correct :)

ocharles: could the boolean be changed to a list of discs to touch? so any edited discs can be removed from the list and get regular "edit medium" edits (if neccesary).

yea, I was going to suggest that

but that's also fairly hard to vote on

"Edit release artist on mediums 1, 2, 3, 4, 5, 7, 8, 9" or even "except 6"

"medium 6" is pretty useless to voters

well, you can display the mediums with a bit more details.

I expect the big classical composer boxes to have disc titles

Edit release artist on:

- CD 3: Stage Works II

- CD 5: Symphonic Works II

- CD 29: Early Works and Rarities

if the list maintained in the edit is a list of medium row ids, that shouldn't be a lot of extra querying.

well... it gets us somewhere, yea

if you want to think on it some more, I'm not in any hurry to work on it :)

my thoughts aren't really getting me anywhere. the only real solution I'm gravitating to is that it should support 180 disc releases :)

but it's non trivial to get there

hm

home time

heh

I mistakenly wrote a space in the label field and it tried to create a new, " " label in Add Missing Entities

reosarevok: hm. sounds related to some othe recent fix.

reosarevok: add "not fixed for labels" to http://tickets.musicbrainz.org/browse/MBS-2817 and re-open. please :)

warp, done

meh. Still at work... might be about to go and have work-ish beers... looks like I'm gonna miss the meeting.

:-(

For the record, all I was going to talk about was "gzip good, gpg signing good, how do we roll out the gpg bit"

:)

anyone wanna make a quick buck?

hah

ruaok has changed the topic to: Agenda: Reviews, MBS-3161, MBS-1837, MBS-2590, MBS-2522

Meh

Someone posts a MB related job and it is one I don't know how to do :p

mb related job?

warp: see ruaok's link

ah

read: someone is too dumb to download and run the vm. :)

and they have $500 to prove it.

heh

Say, ianmcorvidae, didn't you want money to come to the summit? :p

yum

haha

not a terrible idea

lol

https://lh4.googleusercontent.com/-gCsR9EztrRQ/... haskell cambridge hackathon

nice male to female ratio there