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