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
