#musicbrainz-devel

I wonder if the weather had something to do with it

US banks \o/

yeah

lets keep track.

?

but re: the cover art, nikki, are you just suggesting that we have it be "first in the ordering" rather than a new checkbox, or some sort of hybrid "marked front/ordering" mix?

the former I guess

ruaok: I'm trying to get a better handle on the options :P

I don't think I like a back cover showing up if a medium is available.

nikki: so, building on that, if there's something marked 'front', but there's a 'medium' image in the first position, which would you show?

(to me the frontiest image would probably just be the first thing out of the first thing marked as front, the first thing marked as medium, the first image we have at all)

(and I usually order things front, back, medium)

okay

I like what nikki's saying, which, to summarize: caa.org/whatever-de-doo/front is "the first image marked Front, if we have one, else the first image marked Medium, if we have one, else the first image"

I think.

I like that it doesn't require us to define a whole long list of fallbacks, and that it doesn't require changing the image editing interface at all

+1

hrm, I don't like changing the meaning of an existing API

warp: it isn't

unless we documented it poorly or it got changed while I was focusing on school, /front is supposed to give the most representative image

ianmcorvidae: currently /front takes the first image marked as front. you're changing that include non-front-marked images.

which is what we're defining by that fallback

right now we've defined "most representative" as "the first image marked as front", and we're redefining that, but I thought we had defined the API as returning an appropriate representative image, not as "it'll give you an image marked Front"

still, API clients which only want front-marked images will now have to request index.json first to see if the image they're getting is front-marked or not.

now, people may have used the API on the assumption it would only give them images marked Front (which I'm saying was incorrect usage), or we might have misdefined it in the documentation

> Fetches the image that is most suitable to be called the "front" of a release. This is intentionally vague

I'm not entirely opposed to that, but I do think at the very least it warrants a blog post + appropriate wait for clients to adjust their code if neccesary.

(that was from http://wiki.musicbrainz.org/Cover_Art_Archive/A...)

we can certainly blog-post about it now to remind people of the definition and mention that we're likely to change it as soon as we get to fixing that ticket

so, can we call that a consensus?

I wonder how many releases are even affected

+1

one potential other concern with this that I have is for the third part of the fallback -- people aren't always good about actually setting the type to Front, and right now that at least is obviously broken

ruaok: yes, that seems fine. I'd double check with paul though, just in case it affects tagger users (I don't know how he implemented the cover art bits).

I haven't seen him around.

but thinking about it that's probably fine, we have plenty of things like that anyway

so yeah, seems fine to me

onward then.

next please nikki.

wontfix

as I say already :P

very much so

+1 to wontfix

ok, motion carried.

next.

I would +1 doing a redirect

but I don't think we really need to display anything on the page

just a redirect seems fine

+1 to redirect.

that doesn't actually fix it as far as paul cares, I don't think

oh, no, he does mention the URL

so sure, that's fine

+1 to redirect too.

right then. motion carried. onward

it means our URLs are canonicalized in a more reasonable way for search engines anyway, so cool.

I guess the reasoning is roughly "then picard can show them in the release group dropdown more easily"?

that seems fine

I don't recall exactly why it's DR, but possibly to do with returning too much nested data in the ws

but I still agree with the ticket since I opened it :P

+1

is there a reason picard can't use a release browse request by RG?

+1 too. lets fix this in the upcoming ws fixup.

that being the canonical way to do this sort of thing

hm, I think it does use a browse request now. I'll have to investigate

I think we need to better document why lookup vs. browse is the way it is, but if it's doing that then I think it's fine

bitmap: if you find something odd, we can discuss next week.

the nested concern I would have is just that this means we're including things a few more hops in the graph away from the originally looked-up entity, which theoretically is "wrong" -- but, of course, we do it already extensively for release stuff because it means taggers don't get screwed by ratelimiting

so I think maybe for now we should document what picard is doing and reconvene on the resolution of this issue

if we include barcode but not catno, that seems wrong to me, because they're at the same level

yeah, I mean, it's all horribly inconsistent, so maybe it doesn't matter XD

(also I suspect this is the problem I had the other day when I ended up replacing catnos with "fucking webservice" because I couldn't get them from the webservice in my query :P)

and countries didn't used to be other entities so they're in for historical reasons but theoretically are also wrong in the same way, and etc.

so yeah, I guess it's fine to put it in

I'll have more info re picard next week. but it seems correct, and useful judging by the votes

onward?

I think we can say we want to do it, but if you could put a comment about how picard's doing things now that'd be nice just for having more centralized info on the ticket

I would say wontfix, given the direction we're going

given that we want more pages to do more than one thing at once, yeah, I think so

single-use editing pages are something we want to get rid of anyway

+1

and this only makes sense for those, so

What's the "direction we're going"?

Ah.

Yeah.

+1

there's not many places it'd make sense later, so +1 to wontfix

next

http://tickets.musicbrainz.org/browse/MBS-3125 is DRed but the last comment was "We agreed these changes are acceptable", I assume we decided that before and just didn't reopen it?

giant comment is giant

reading it XD

yeah, seems fine.

mark as non-DR, move on, I Think

+1

I'm not sure that's really such a big problem and is sometimes correct anyway

wontfix

at most we could add a warning, though I'm not sure it's a very common problem. so I'm leaning towards wontfix

don't particularly care either way , either is fine

+0

the preview in the release editor at least shows the artists used, so it's not like you can't see it

so yeah, I'm leaning towards wontfix

ambivalence with a slight tendency towards wonfix. :)

wonfix and last ticket!

+t

not one I expect a decision about, but http://tickets.musicbrainz.org/browse/MBS-3235

mostly I'm wondering what we should do next with it, since people do have some use cases we can't really solve in another way

too much engineering effort for something which doesn't sound all that useful, I say wontfix.

it mostly seems to just be asking for release entities that don't need tracklists? or are there further restrictions on what these supposed release stubs can/can't do?

it's mainly just releases without a tracklist, yes

cd stubs have become this red headed step child anyways. not sure we need to put more effort into it

this isn't about cd stubs

I sort of agree with it not sounding that useful, but I'm fine with it moving to being a "sure, submit a patch if you want it" ticket

I reaaaally want this

yeah, entirely unrelated to cdstubs

ah

this seems very un MB'ish.

possibly helps to make cdstubs go away, even :P

so many old things you just can't find a tracklist for

I'm with the droid.

I can see the usefulness for historical releases but slightly concerned about editor laziness misusing it

how is it mbish? music encyclopaedia not tracklist encyclopaedia

bitmap: yeah, that's been my concern all along

well make it an advanced option

I agree with reo on this, I guess

hidden by default or something

I'd rather have lazy editors enter no track list than a bad one.

MB in the sense that we want complete info.

this is just saying "this exists but we don't know much about it"

ruaok: bull

we have HUGE amounts of stuff with woefully incomplete ARs

ruaok: the problem the editors have is that they can't enter *any* information because they don't know the tracklist

ruaok: It's more complete to acknowledge that a release exists than not having any mention of the release at all.

ruaok: as you said yourself, imperfect info beats no info ;)

oh jeez. ok. ok.

we want correct information, but I don't think we care that much about 'complete' :P

well, then that settles it, no?

sort of?

it seems we agree it's useful, but we're not sure how to avoid lazy editors from misusing it

which I guess is progress, we can ask the people who want it if they have any ideas :P