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. |