1 |
> 1. Should the project be focused on reference/most common |
2 |
> implementations, or maybe more of them? Say, giflib vs libnsgif. |
3 |
> I think the latter library is specific to a few programs right now but |
4 |
> if it gets more popular, it would fit. |
5 |
|
6 |
It's mostly a question of critical mass. To give an example from a different |
7 |
corner of Gentoo... |
8 |
|
9 |
Initially net-libs/libtirpc was more of an obscurity, a more feature-complete |
10 |
replacement for code within glibc. Back then it didn't matter so much who |
11 |
maintained it. |
12 |
In the meantime, the corresponding part of glibc has been phased out, and |
13 |
everyone is relying on libtirpc. So now it's important that it is well- |
14 |
maintained, and it's taken care of by base@. |
15 |
|
16 |
> 2. How many kinds of media should the project accept? Audio, graphics, |
17 |
> video seem pretty obvious. Containers too. libass makes sense as it is |
18 |
> specifically for video subtitles. Anything else? |
19 |
|
20 |
Again, critical mass should be the main criterion. Things that are used by |
21 |
many different packages, with many different maintainers. |
22 |
|
23 |
If a library is only used by LibreOffice, it makes more sence that it is |
24 |
maintained by office@. If a library is used exclusively via kde-frameworks, |
25 |
the same for kde@. |
26 |
|
27 |
I wouldn't be too restrictive regarding the type of media. |
28 |
|
29 |
> 3. What about libraries implementing media-specific streaming protocols? |
30 |
> E.g. libshout, live... I suppose the ones specific to voip would fall |
31 |
> into voip project's domain instead. |
32 |
|
33 |
Same arguments... |
34 |
|
35 |
> |
36 |
> |
37 |
> [1] |
38 |
> https://archives.gentoo.org/gentoo-dev/message/79073ab9c7cebd79fc12e897e110 |
39 |
> bc3c [2] https://wiki.gentoo.org/wiki/Project:Codec_project |
40 |
|
41 |
|
42 |
-- |
43 |
Andreas K. Hüttel |
44 |
dilfridge@g.o |
45 |
Gentoo Linux developer |
46 |
(council, qa, toolchain, base-system, perl, libreoffice) |