#musicbrainz-devel

true

ruaok_: i will try and do that

ocharles: grand

but i can't promise it will reflect reality

try, please

(though I will certainly try)

ianmcorvidae: so i'd say have a think about that, and see what feels best to you

i'm ok with any of the options, you're doing more work than me, so I should try and fit your workflow

right then. done with that topic, are we?

I'll prod you periodically and do one or the other of the things for ensuring more hands-on testing (post-commit review, sandbox, whatever way)

and yup, I'm satisfied

nikki: do you have some DRs for us?

I can get some

we have plenty :P

lets do a couple of them at least.

http://tickets.musicbrainz.org/browse/MBS-3700 this seems like a wontfix to me

wontfix seems good to me

+1 for all the reasons in the comments

yep, bad idea.

+1 wontfix, that is

wooontfix

I'm inclined towards "leave it alone" because it's easier that way :P

+1 from me, it's easy enough to construct the full URL anyway

it feels too late now

agreed.

I'm not quite sure what that ticket wants

for add medium edits to be votable when adding a release

ianmcorvidae: "We should have a foolproof."

thats what

heh

didn't we do that earlier and it was a problem?

we already made them auto-edits because otherwise we ended up with releases in an inconsistent state

how common is this problem?

we'd need a way to fail edits when other edits fail, I think, is the issue

because we'd need the add release (and associated things) to fail if the add medium does

and if the release requires more work to fix than it would to just re-add it, I don't see why people can't just vote no on the release add

right, you need to still treat the add release edit as (mostly) atomic

I think the better solution is to display the already-votable edits with better information (e.g. the tracklist)

in terms of voting on this ticket, it doesn't seem feasible

and otherwise, people can vote on the add release

yeah

so, anyway, I think we agree on wontfix?

i think so, yea

I'm not sure I have an answer to ruaok_'s last question, if someone else does then I guess there's that

well, there is consensus on what to do. thats what matters. onward.

in general the trend is away from XML and more towards json.

ijabz comment there is lessened now that we have json bindings for our WS.

me personally, wontfix.

i think wontfix because we struggle to support two formats in MBS

ianmcorvidae?

I don't know that I particularly care, but I don't know that the implementation effort would be worth it

we do have a separate libcoverart now anyway, as I recall

anyone object to wonfix?

so the original reason for the ticket is also a bit diluted

+1 to wontfix

wonfix and onward!

\o/

http://tickets.musicbrainz.org/browse/MBS-3411 asks for allowing some discogs links that we currently block (largely accidentally), but I've since learnt that they're some sort of purchase links and would be fine with just making sure they can be used with the purchase for download relationship

I'm ok with that suggestion.

sounds sensible

works for me

http://tickets.musicbrainz.org/browse/MBS-6387 didn't we decided to wontfix this already? :P

correct. onward.

http://tickets.musicbrainz.org/browse/MBS-2255 it seems here #3 is the best solution since we have filtering by subscriptions for reports

the reason its not closed was to give ben time to gather more support for his side.

I think 6387 should be closed now.

ruaok_: just closed it

thx

2255 my last comment from april still stands, and agrees with nikki

heh

unless I've misunderstood something in the options ocharles had outlined

I'm fine with #3.

motion carried and onward.

http://tickets.musicbrainz.org/browse/MBS-2638 here it's not clear why tags or artist dates aren't sufficient and there are no votes for it either, so I think wontfix

yea, i agree that 3 is the best way

I'm leaning towards wontfix, but using tags is fine too.

nikkis comment about being able to compute that info is spot on

not quite

there is a reply later saying it's not that simple

the borders are rather fuzzy, yes

if you extend work attributes to artists, then maybe this is something for artist attributes

some composers it's easy, but for others it's stylistic

there is a finite domain of periods, yes?

yes

I'm fine with wontfix, this is almost genderish

you mean genreish?

ianmcorvidae: yeah, toss that into the discussion bin for the CSummit.

it doesn't seem like something you necessarily want to wontfix

i think it should remain at DR

the nicest solution would be something like the dynamic attributes

Postpone for 6 months

leave it open for now.

yea, for after that summit

onward.

okay

I'll comment to that effect

next?

http://tickets.musicbrainz.org/browse/MBS-3645 we created this at the rotterdam summit but it has very little support

if people don't want it, then fine. ditch it.

this is somewhat related to the period ticket.

maybe we should take it up in the context of classical.

only in a very vague way

i'm not so keen on this idea, so i'm ok with a wontfix :)

but I don't really know on this topic, anyway; I think that the specific "century column" idea isn't liked though

wontfix then.

onward.

I don't know if the ticket needs to stick around for a different solution to the same problem or not

I think there's another ticket for date uncertainty, isn't there?

The idea as laid out in 3645 doesn't seem like the best approach, Vaclav's comments are a bit better.

http://tickets.musicbrainz.org/browse/MBS-975 and http://tickets.musicbrainz.org/browse/MBS-4937 are both pretty much asking for merged mbids to redirect to the canonical one, which I agree with but ocharles will surely say "but there is no canonical one!" :P

nikki: lets discuss this in january. :-D

haha

:)

srsly, I dont wanna talk about that now. :)

ok

we're on a streak. shall we pick a couple more?

http://tickets.musicbrainz.org/browse/MBS-2294 is about showing edits for works under more artists

it seems ollie set it to decision required but I'm not sure what exactly needs deciding

heh entity-edit links

ianmcorvidae: whats wrong with STFU? :)

:)

I'm not sure what the proposed additions are in 2294

2294 seems reasonable to me.

is it some sort of "determine the supposedly-primary artist and link to that one" or "link to all artists we think might be related"

ianmcorvidae: I don't think it should wontfix'd unless Vaclav's comments are in another ticket. Which I'm trying to find, but haven't yet.

3645, that is.

so should we postpone it until next week and try and figure out in the meantime which entities/relationships/artist credits should be included?

if someone's taking on that task, then sure

I can at least have a look when I'm not busy trying to find things to discuss :P

MBS-2954 ! Found it!

Feel free to wontfix 3645 now with no objection from me now. :p (2954 is also DR though.)