#musicbrainz

$wgExtraNamespaces[100] = "History Talk";

er, $wgExtraNamespaces[101] = "History Talk";

At least that's what I think from reading http://www.mediawiki.org/wiki/Manual:$wgExtraNa...

pronik: try now

seems to work, both namespaces appear in search

thanks

cool

question: for a 2 disc release, there are two versions: 1. standard version. 2. japanese version where disc 2 has a bonus track. So in MB there is only one disc 1 (with two release events), and two disc 2 (each with 1 release event). Should the PartOfSetRelationshipType be applied to both disc 2s?

two different sets, so I would guess yes

I would think so too, but it looks weird at disc one, having two disc 2's ;)

I would say they should have the box thingy ticked though, 'cause the second disc only applies to certain release events, not every release event... but it's kinda confusing 'cause the wording changes

wow. street clashes in tehran and LA.

one over democracy and one over... basketball.

maybe the AR should be on the release events instead of the release ;) but NGS will fix all that..... (I have no idea, but I can pretend ;)

it will

woohoo \o/

I seem to remember suggesting that we have an attribute to say that the next disc isn't a part of a set with every release event so that ngs could convert the data easier and that's what the linking text implies to me...

but the page to add the relationship says 'bonus', so does the wiki, which means something else to me

well, sometimes it works, sometimes it doesn't

as far as I can tell, the current AR only speaks about it being a bonus disc or not

like I remember linking a disc where one release had extra tracks plus a bonus disc... the bonus disc always came with the release with extra tracks, there's no release events on the main disc which don't have the bonus disc

so to me it makes no sense for it to say 'may be part of a set' when it's always part of a set in that combination

that makes sense

indeed you were.

hi! :)

do you remember what we intended the attribute for the part-of-set relationship to mean?

which one?

the bonus/optional/may-be-part-of-set thing

i.e. was it supposed to be used for when the second disc didn't apply to all of the release events, or when the disc was a bonus disc, whether it applied to all the release events or not

"If the first disc in this relationship is available separately without the second disc, the second disc is a bonus disc. A checkbox is used to indicate whether the second disc is a bonus disc."

what about when there's release event X, with discs A and B, and release event Y with discs A and C? there's always a second disc, but not always the same one?

that's the wording in the guideline, from that I think our intent was that a release which always has two discs shouldn't have the bonus disc checkbox checked (regardless of wether the second disc is called bonus disc or not).

this may not have been communicated clearly enough, so I don't think we can rely on everyone using it in this way.

nikki and brianfreud are back. and keeping warp busy.

it feels more like MB here now.

:D

I know it wasn't clearly defined, I was just trying to find out what we originally intended

I know my original intention was for it to say whether the relationship applies to all release events or not, but I don't know about other people :)

nikki: what about when disc 2 is a 2 in 1 but only iion of the set, whereas the other version has 3 separate CDs instead? ;D

nikki: yeah, technically the wording in the guideline agrees. the wording of the checkbox itself really doesn't make it clear though.

what's an iion?

I have the feeling that most people apply it on a "is titled a bonus disc or not" basis

iion = in only one version

brianfreud: pagh, weird edge cases :P

the wording does make sense for both meanings though, in most cases

so it could just be that we overlooked the ones where the meaning diverges

it's too late to really change it now, I guess, anyway... but I was still curious

warp, I know, just teasing :)

if anyone else uses the LMA, btw, I have a LMA GM import script in testing - going for a nap now, I'll be putting it up on userscripts tonight (along with the amazon import script)

there are only 81 discs which are the left side of more than one part-of-set relationship anyway, so they can be reviewed by hand

ah, that's not so bad

and 26 discs which are the right side of more than one

should DVDs really be added? http://musicbrainz.org/release/c5afd601-d8f4-4d...

yes

but that looks a bit weird

like if it's a dvd, why is the release event a cd? o_O

and I wouldn't put dvd in the title either

luks: which bit don't you like about the patch?

no me neither

I was thinking of voting no though as it seemed odd

It's just serialization, but I had to write my own serializer, because we didn't want package names sprinkled in the data

oh, is there a reason why ngs currently has a huge messy annotation for release groups and no annotations on the actual releases?

aCiD2: I don't like that all the patch does is serialization, and I already can't follow it

aCiD2: it seems unnecessarily complex to me

That's why I prefered to use MooseX::Storage

but that doesn't give us usable output

scrap my patch then, how should it look?

I'd wait for ruaok to have a look

I really want to avoid having every class implement a "serialize" and "restore" method

me?

I'm quite a ways behind the current state of NGS due to RG.

not sure I can give a meaningful response.

aCiD2: the way I work is that I unless I'm completely sure about something, I do the simplest possible thing and leave it for later

ruaok: this is not really about NGS

So do I usually

But I know for a fact, that just about all the edits will be stored the same way

aCiD2: I don't see how things like tracklist changes will be handled

so I'd try to avoid spending X days to design something final

I'd just use a plain hash and work on the accept/reject methods instead

but that's just me personal opinion

my

right, but that's a very important opinion :)

well, ignoring serialization, how do you want to represent new/old pairs?

the "Change" type was the only sane way I could see to do that

my $data = { new => { name => "Foo" }, old => { name => "Bar" } };

And say good bye to all sorts of type constraints?

I wouldn't say good bye to the because I never had them :)

luks: i can do it that way, but what about using http://search.cpan.org/~flora/MooseX-Types-Stru... ?

but yes, I don't think the type constraints are useful there

aCiD2: what are the advantages?

ok, let me mock something up using MooseX::Types::Structured

It'll be small and quick

morning kids

aCiD2: the thing is, I don't *really* care about this. we should not focus on the serialization, we should focus on the actual edit types

but what I think you are doing it restricting yourself for reasons I don't understand

I know, but those are trivial

Hmm, maybe (probably)

you are building a framework that has limits and I expect you to hit the limits

I'm meandering, because I don't know how it should look

or really what it needs to do

I'd approach it from the other side

implement accept/reject of a few edit types without having the data

how can I test that?

you don't

it's just to see what kind of structure you will need

i see

brianfreud: http://musicbrainz.homeip.net/ws/priv/release-g...

Picard is having issues loading a couple of albums

from the looks of things, the web page itself is having issues with the same albums

specifically, Switched-On Bach by Walter Carlos

darkaudit: which album exactly?

outsidecontext: one sec to get the exact id...

DarkAudit, i got it, thanks

the problem seems to be the cover art from amazon again

seems to happen frequently in the last time

disable the cover art plugin for this album as a workaorund

ok... the Wendy and Walter Carlos albums are the only ones having issues with this on my end

maybe it is the same problem as with http://musicbrainz.org/show/edit/?editid=10765435

luks: are you stil around?

natta

MClemo: no, it's the cover art link. http://crawls.archive.org/katrina/2008040103314... it's not amazon as i thought first