D27973: kcddb 6
Harald Sitter
noreply at phabricator.kde.org
Thu Mar 12 11:32:38 GMT 2020
sitter added a comment.
To clarify: the options as I understand them are:
a) use gnudb instead of freedb (which wouldn't require any API change?)
or
b) use musicbrainz exclusively (the diff at hand)
Under the assumption that we want to have b), the diff looks fine to me. I have no particular objections to going with a) either, in which case this diff I guess would be moot in general. I'll leave that for someone else to decide, I have no horse in the game here and thus have no feelings one way or the other.
I would however argue for b). Subjectively I'd say there are much fewer users of CDs in general and even fewer dealing with CDs on computers which does call into question whether we should support two backing info-lookup systems considering there's twice the amount of code to bit rot and twice the amount of testing that technically would need doing for changes (not that there are changes ^^). Under that view point shrinking the library seems like a very reasonable thing to do and going with musicbrainz is probably the better choice as there seems to be more interest for it (and thus more/better data one presumes) than for freedb/gnudb. According to google trends anyway.
REPOSITORY
R348 KCDDB Library
BRANCH
master
REVISION DETAIL
https://phabricator.kde.org/D27973
To: aacid, sitter
Cc: ltoscano, wbauer, pino, sitter, heikobecker, rstephenson, kde-doc-english, gennad, fbampaloukas, skadinna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-doc-english/attachments/20200312/0aa685e9/attachment.html>
More information about the kde-doc-english
mailing list