Re: MultimediaFetching Tools
(just replying to the list)
Hi,
I maintain src:glyr which is in this list. Unlike most of these
packages, glyr only deals with metadata like lyrics and cover art, so
I would argue that it is not really comparable to the other ones and
does not need to be in this list. Here are my answers for glyr:
> - is upstream still alive?
Yes
> - how active is it?
The library (and companion program glyrc) is mostly stable so there is
little activity besides adapting plugins to changes in source
services.
> - do we have good relations with them? If not, why?
Yes, the author is very reactive and I've been happy with him.
> - what should be added/removed in our table?
> - what features should we compare to keep it clean and simple? So we
> don't create too much irrelevant information to parse and this isn't
> competition of package features.
> - other ideas (rewrite intro sentences to improve and make more clear
> our idea, make the effort more public via news feeds, starting drafts
> on our intro mail to upstream developers).
Important questions IMHO include:
- Is it specific to a particular website?
- Is the primary purpose of this package to download media from third
party sites (ex: quvi - yes, mpv - no, it's a media player).
- Does it rely on a supported API or scraping?
- Does upstream provide stable versions?
The last two questions are related to the particular situation these
packages have in the archive since they (1) depend on an external
service that (2) changes frequently, sometimes unexpectedly.
Because of (1) I think that they should maybe go to contrib, though
its current definition only mentions third party software, not
services. And to deal with (2) we now have stable-updates but it
obviously needs an upstream stable branch.
--
Etienne Millon
Reply to: