Gentoo Archives: gentoo-dev

From: Alexis Ballier <aballier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Codec project
Date: Fri, 12 Jun 2020 15:17:18
Message-Id: 20200612171705.5f9d983c@gentoo.org
In Reply to: Re: [gentoo-dev] [RFC] Codec project by Rich Freeman
1 On Fri, 12 Jun 2020 10:58:24 -0400
2 Rich Freeman <rich0@g.o> wrote:
3
4 > On Fri, Jun 12, 2020 at 10:33 AM Alexis Ballier <aballier@g.o>
5 > wrote:
6 > >
7 > > What about /j #gentoo-media, discuss, join the current projects,
8 > > get a few things done (there is a lot of choice there ;) ), maybe
9 > > orphan unmaintained players/viewers, or check if they are
10 > > maintained and hand them to a specific maintainer, and then see
11 > > about merging or splitting all those projects *after* gaining
12 > > experience and knowledge about the peculiarities of some of those
13 > > packages ?
14 > >
15 >
16 > Probably best to leave the details up to those doing the work, but I
17 > would suggest this as a guideline:
18 >
19 > Keep the scope reasonable. If you expand the scope to a point where
20 > 90% of the project members don't care about 50% of the project scope,
21 > then you're setting yourself up for a repeat of the past. You want
22 > 80% of the project members to be interested in 80% of the packages
23 > being maintained ideally. Sure, there will be little niches that a
24 > subset are more interested in, but you want to keep it focused around
25 > a core where coordination makes sense. You can have different roles
26 > in the project but it should still be one project.
27
28 Totally agree here. Back in the days we had split proaudio from sound
29 for this very reason.
30
31 > If most of the project members aren't talking to each other about most
32 > of the things they're doing in the project, then it isn't really a
33 > project - it is just a category tag. The point of a project is to
34 > coordinate things that actually NEED to be coordinated or at least
35 > benefit from it in some way.
36
37 It is not like a KDE, gnome or gstreamer project that has very tight
38 coordination needs, so we shouldn't judge those on the same grounds, but
39 from time to time, when a core library changes its API it needs a
40 project-wide coordination (plus a few extra revdep here and there that
41 you get to know over time). That's more how I see coordination there.
42 It is not as critical nor as frequent as it used to be but still
43 happens from time to time. Having a codec project goes against that
44 IMHO, we'd end up with a category tag where there's no relation between
45 any of the package except they're media libraries.
46
47 Alexis.