[mb-style] RFC: Change BoxSetNameStyle

[Chris B]

On 28/03/2008, Brian Schweitzer <brian.brianschweitzer at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 6:18 AM, Chris B <chris at whenironsattack.com> wrote:
>  > On 27/03/2008, Brian Schweitzer <brian.brianschweitzer at gmail.com> wrote:
>  >  >  > I'd rather not wait until NGS for this! Merging releases is the best way to ensure this. If there are fewer releases,
>  >  >  > we increase the chances of completeness of each of them. Granted, NGS will probably merge the ARs. But this
>  >  >  > may not happen before a few years.
>  >  >
>  >  >
>  >  > I'd suggest you check the test server again.  luks has had track
>  >  >  merging on there for testing for over a week now, and everything I've
>  >  >  heard in IRC has suggest that that will be part of the May non-schema
>  >  >  change server update; surely less than 2 months isn't too long for you
>  >  >  to wait?
>  >
>  >  track merging is not the same as release merging. release merging was
>  >  covered in ReleaseGroups and (as I understand it) is slated for 'NGS'.
>
>
> I'm not sure I see your point; It's not a question of what is or isn't
>  "NGS". - the suggestions about ARs having any bearing here would all
>  seem to be relevant mainly for track ARs, yet the release grouping
>  concept section of NGS has no involvement with track ARs.
>
>  My point is, if the argument is that allowing both boxed and unboxed
>  release listings to exist is bad as it lessens the chance of any
>  release ever being AR'd, under a system which allows merged tracks,
>  where each release instance of that merged track has the ARs for the
>  merged whole, then this argument no longer is valid; rather than
>  decrease any chances, it actually would tend to increase them, by
>  exposing the track in more instances, and allowing for the greater
>  chances that someone might do ARs to any one instance.

right, well ARs don't mean much to me in this instance, only
ReleaseGroups. ReleaseGroups (at least, the NGS implementation) would:
- allow one to tag against a basic tracklist of a studio album,
ignoring product specific info
- allow one to tag against a product-specific tracklist of a studio
album (including boxset details, etc)
- allow us to go nuts with format info, collections, etc, without
risking clutter

it'll probably be inter-release AR links that form the groups in the
first place, but it's not quite so simple - you still have to put
together a master tracklist, or is that generated by common tracks? i
don't know...this seems to be in the air. anyway, these are
inter-release ARs, not track ARs, so it's a different AR matter
entirely.

so for me it's simple: grouping functionality first, release
redundancies second. you might think all these releases are relevant,
but i don't. the rule is now 'don't add them' and the reasons are
manifest, but ultimately if you don't care about the benefits of a MBz
music-based discography over a discogs-ish product-based discography i
can't convince you otherwise.