Defining how pseudo-releases should be used (STYLE-342)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Defining how pseudo-releases should be used (STYLE-342)

Nicolás Tamargo de Eguren-2
Hi!

Something that has been stuck for quite a while is how to deal with pseudo-releases and duplication, at least until we have a way to just store the alternate info as part of the standard release. Some links to previous discussion can be found in http://tickets.musicbrainz.org/browse/STYLE-342

While my preferred solution to this (and that of at least a few other people) would be to just block fields like label, catno, barcode and dates in the code so that they can't be filled at all, I find the proposed solution from that ticket's first comment a fairly acceptable compromise: 

  • If a pseudo-release is linked to an original release, the pseudo-release should duplicate as little data as possible - it should generally only have the status, language and script, medium names, track names, track artists and of course the release name and artist since those are required. Any other data which can be taken directly from the original release should not be added to the pseudo-release (track times are probably acceptable).
  • If the pseudo-release is not linked to an original release (e.g. the original isn't in the database yet), it would be acceptable for data to be stored on the pseudo-release.
This ensures that we don't have to enter one pseudo per original release when the tracklists are the same anyway, keeps label entries etc. clean, and still allows people who can't enter the official version for some reason (because they can't read/type Japanese or whatever) to enter enough data so that their version can be later found and matched to the right original.

I'm going to be direct about this and say that unless I get very convincing arguments against this, I'll be eventually implementing something pretty similar to it as the guideline. That said, I'm happy to get suggestions on small improvements, changes, or just your reasoning for the idea being absolutely wrong :)

A note: I do know that Picard doesn't deal very well with this now (although see the last bits of that comment for a few things that soften it). But (apart from the general view that the data is the main goal and the software should adapt to it) we've been waiting to do something like this for ages in hope of Picard implementing better pseudo-release support and it never happened, so maybe doing this will finally make someone who cares about how this works in Picard write the relevant code :)

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Defining how pseudo-releases should be used (STYLE-342)

KRSCuan
Commented on http://tickets.musicbrainz.org/browse/STYLE-342. I guess
further discussion should also take place there.

TL;DR I'm firmly against such changes, as we should focus on the long
run and get rid of pseudos completely. Once we can duplicate their
functionality in main releases.

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style