Caught exception in MusicBrainz::Server::Controller::ReleaseEditor::Add->add "Can't use an undefined value as a HASH reference at lib/MusicBrainz/Server/Wizard.pm line 269."
Admittedly, having the countries *and* Europe looks bad
2012-05-27 14831, 2012
SultS
I would not merge any of these without searching for more info. some releases may look just look similar, there have similar looking catalog # numbers, but none of those are exactly identical based on the information presented
2012-05-27 14856, 2012
Anoia
I'll leave them then
2012-05-27 14807, 2012
Anoia
I'm fairly new to the musicbrainz world
2012-05-27 14812, 2012
Leftmost joined the channel
2012-05-27 14833, 2012
SultS
1st two are most likely the same (UK) release though
2012-05-27 14822, 2012
SultS
they share the discogs and amazon URLs besides having UK release date
In any case, I don't have a strong opinion on this matter - before I would have said "together is best" but since the covers are likely to be somewhat different, even if only because of the legal text, now I can see more arguments to keep them separate I guess
2012-05-27 14827, 2012
reosarevok
(although taking that opinion too far leads us to 100 different releases for cases like limited editions of 100, where each cover is handmade :D)
2012-05-27 14856, 2012
gnu_andrew
reosarevok, I think making the tracklist more visible demonstrates clearly there's not a huge load of data duplication going on
2012-05-27 14837, 2012
reosarevok
Well, the tracklist says nothing but "these share all recordings in the same order", doesn't it?
2012-05-27 14855, 2012
reosarevok
So it's something that you don't need a tracklist to see
2012-05-27 14812, 2012
reosarevok
Dunno
2012-05-27 14839, 2012
reosarevok
I guess the main issue at hand is that we have three levels, somehow
2012-05-27 14806, 2012
reosarevok
RG, "a bunch of very similar releases which only differ on release date/country and legal text", release
2012-05-27 14817, 2012
reosarevok
But making that second one explicit is pretty hard
2012-05-27 14834, 2012
gnu_andrew
reosarevok, which is important. But ideally I'd like to have ARs on tracklists too
2012-05-27 14805, 2012
gnu_andrew
you do need the tracklist to know that releases are sharing the data and not duplicating it
2012-05-27 14857, 2012
reosarevok
Even if they were duplicating a list of names, how's that even relevant?
2012-05-27 14807, 2012
gnu_andrew
and the tracklist also has different titles to the recordings
2012-05-27 14808, 2012
reosarevok
The only problem would be duplicating recordings I'd say
2012-05-27 14855, 2012
reosarevok
I mean, one release for Bulgaria might have all the titles in cyrillic, thus a different "tracklist", and still be considered the same thing-ish I guess
2012-05-27 14808, 2012
gnu_andrew
take the case where there's a typo that applies to a tracklist which is shared
2012-05-27 14809, 2012
reosarevok
(same credits, same all)
2012-05-27 14820, 2012
gnu_andrew
it should be possible to edit it at tracklist level rather than release, so all get the fix
2012-05-27 14810, 2012
gnu_andrew
if something exists and is part of how the underlying data works, it should be visible in my opinion
2012-05-27 14816, 2012
gnu_andrew
hiding it just makes things confusing
2012-05-27 14818, 2012
reosarevok
I think that one is by design
2012-05-27 14826, 2012
ZaphodBeeblebrox joined the channel
2012-05-27 14831, 2012
gnu_andrew
well then it's the wrong design, we should have the option
2012-05-27 14832, 2012
reosarevok
To avoid people changing releases they don't have
2012-05-27 14850, 2012
reosarevok
Or, well, to be sure they don't change what they don't know about
I would rather just have an userscript for that, if at all
2012-05-27 14831, 2012
reosarevok
But well
2012-05-27 14801, 2012
gnu_andrew
I don't even know what these userscripts are so I doubt casual editors do
2012-05-27 14814, 2012
reosarevok
Casual editors shouldn't probably be batch-editing...
2012-05-27 14832, 2012
reosarevok
I think the issue people have is not really that stuff becomes hard to correct, though
2012-05-27 14841, 2012
gnu_andrew
certainly my issue
2012-05-27 14848, 2012
gnu_andrew
the legacy feat. case is an obvious one
2012-05-27 14857, 2012
reosarevok
But that we display loads of times what seems to most people to be the exact same thing
2012-05-27 14814, 2012
gnu_andrew
how so?
2012-05-27 14836, 2012
reosarevok
Well, with the strict "one date, one release" thing
2012-05-27 14848, 2012
reosarevok
If I have the disc, and start selling it one day before the official date (happens all the time)
2012-05-27 14852, 2012
reosarevok
That's a new release
2012-05-27 14801, 2012
gnu_andrew
yeah I know
2012-05-27 14820, 2012
gnu_andrew
but this is more a UI issue than one that means you should merge all the releases together and lose data
2012-05-27 14857, 2012
reosarevok
And to most people, a (fairly retarded) system of releasing stuff in different dates in different countries doesn't make it a different thing, I assume
2012-05-27 14828, 2012
reosarevok
To them is "well, I have this thing here, whether I bought it in the UK on a Friday or Germany on a Thursday is irrelevant"
2012-05-27 14857, 2012
reosarevok
Which is why people want to be able to store those dates in the same release, but still be able to serve them in a machine-readable way for those who want that
2012-05-27 14846, 2012
gnu_andrew
which already happens now
2012-05-27 14804, 2012
gnu_andrew
the dates differ per release
2012-05-27 14807, 2012
gnu_andrew
the tracklist is shared
2012-05-27 14828, 2012
reosarevok
But the tracklist is also shared between, say, the digipak, jewel case and CD+DVD editions
2012-05-27 14837, 2012
reosarevok
Which almost anyone would call a different thing
2012-05-27 14858, 2012
reosarevok
(or the CD and the vinyl and the digital, etc.)
2012-05-27 14809, 2012
gnu_andrew
If they have the same tracklist, don't see how they are different
2012-05-27 14834, 2012
reosarevok
If I have a jewel case in my hands vs. a digipak, they're clearly different things, and I can see that they are
2012-05-27 14848, 2012
reosarevok
I can't see, in many cases, whether they are German or British
2012-05-27 14802, 2012
reosarevok
And when I can, it's by reading some very small print
2012-05-27 14825, 2012
reosarevok can perfectly understand why people feel one of those two differences is more important than the other
2012-05-27 14811, 2012
gnu_andrew
well yes I see the point, but I don't see where that gets us
2012-05-27 14832, 2012
gnu_andrew
UK digiback, German CD, whatever. they all have the same tracklist data
2012-05-27 14835, 2012
reosarevok
(and in the cases where there's no difference in what's printed, there's just no way of knowing what you have, even)
2012-05-27 14849, 2012
Anoia
can a release have multiple countries?
2012-05-27 14854, 2012
gnu_andrew
Anoia, no
2012-05-27 14855, 2012
reosarevok
Anoia: at the moment, no
2012-05-27 14801, 2012
Anoia
without going to an entire continent?
2012-05-27 14816, 2012
Anoia
OK, another potential duplicate
2012-05-27 14817, 2012
gnu_andrew
Anoia, but a release is just a tracklist and some URLs
2012-05-27 14819, 2012
Anoia
one with no region
2012-05-27 14820, 2012
xplt
reosarevok: digital release may include one or two "bonus" tracks, which are not on the vinyl...
2012-05-27 14823, 2012
Anoia
one for germany
2012-05-27 14828, 2012
reosarevok
xplt: or it may not :)
2012-05-27 14830, 2012
gnu_andrew
xplt, so that would be a different tracklist
2012-05-27 14831, 2012
Anoia
same codes, labels, etc
2012-05-27 14834, 2012
reosarevok
gnu_andrew: I have releases which were co-released by a French label, a Spanish one, and an Italian one
2012-05-27 14843, 2012
Anoia
what should I do in that case?
2012-05-27 14855, 2012
gnu_andrew
reosarevok, so three release entries
2012-05-27 14859, 2012
reosarevok
They're the same thing, there's no text that says anything about where it was released, nothing
2012-05-27 14807, 2012
reosarevok
There's just one print, with three logos in the back
2012-05-27 14820, 2012
the_metalgamer joined the channel
2012-05-27 14829, 2012
reosarevok finds it hard to argue that's three releases
2012-05-27 14840, 2012
gnu_andrew
reosarevok, so? the info's available that there are multiple releases because you know about it!
2012-05-27 14805, 2012
Anoia
reosarevok: you can have multiple labels
2012-05-27 14810, 2012
reosarevok
Anoia: sure
2012-05-27 14827, 2012
reosarevok
gnu_andrew, but how is that information remotely useful? Would you also add only one label to each one of them?
2012-05-27 14836, 2012
reosarevok
(in this case I don't even have dates, apart from the year)
2012-05-27 14843, 2012
gnu_andrew
reosarevok, depends if there are different dates/countries etc.
2012-05-27 14856, 2012
reosarevok
I doubt the labels even know the dates themselves
2012-05-27 14808, 2012
gnu_andrew
reosarevok, then no, one release with three labels suffices
2012-05-27 14829, 2012
gnu_andrew
reosarevok, my concern, shown by this Eurovision edit, is in throwing away release date data we do have
2012-05-27 14857, 2012
reosarevok
Which is why I don't see the problem if we did have the option to store multiple country/date pairs, if all the rest is the same
2012-05-27 14804, 2012
reosarevok
(so we don't throw away that data)
2012-05-27 14840, 2012
reosarevok
"This thing was made available in different places at different dates, listed on the sidebar"
2012-05-27 14821, 2012
reosarevok
I'd even argue it's better for data users, since they can know it's the same thing with different dates
2012-05-27 14828, 2012
reosarevok
(while if they were separate, they'd have to guess)
2012-05-27 14834, 2012
gnu_andrew
reosarevok, my point is we already do
2012-05-27 14812, 2012
gnu_andrew
reosarevok, this isn't something that needs a schema change, just different presentation and the option to edit shared tracklists
2012-05-27 14815, 2012
reosarevok
Considering a date a primary entity is way too abstract :/
2012-05-27 14842, 2012
reosarevok
If I have that, bought on Germany, and you have that, bought on the UK, we wouldn't say we have different things
2012-05-27 14851, 2012
reosarevok
Well, dunno about you, but almost nobody would :p
2012-05-27 14819, 2012
gnu_andrew
no probably not, but I would guess that a vast amount of MB data comes not from physical releases at all, but online listings, digital releases, etc.
