Re: [gentoo-dev] [RFC] Codec project

2020-06-12 Thread Alexis Ballier
On Fri, 12 Jun 2020 10:58:24 -0400
Rich Freeman  wrote:

> On Fri, Jun 12, 2020 at 10:33 AM Alexis Ballier 
> wrote:
> >
> > What about /j #gentoo-media, discuss, join the current projects,
> > get a few things done (there is a lot of choice there ;) ), maybe
> > orphan unmaintained players/viewers, or check if they are
> > maintained and hand them to a specific maintainer, and then see
> > about merging or splitting all those projects *after* gaining
> > experience and knowledge about the peculiarities of some of those
> > packages ?
> >
> 
> Probably best to leave the details up to those doing the work, but I
> would suggest this as a guideline:
> 
> Keep the scope reasonable.  If you expand the scope to a point where
> 90% of the project members don't care about 50% of the project scope,
> then you're setting yourself up for a repeat of the past.  You want
> 80% of the project members to be interested in 80% of the packages
> being maintained ideally.  Sure, there will be little niches that a
> subset are more interested in, but you want to keep it focused around
> a core where coordination makes sense.  You can have different roles
> in the project but it should still be one project.

Totally agree here. Back in the days we had split proaudio from sound
for this very reason.

> If most of the project members aren't talking to each other about most
> of the things they're doing in the project, then it isn't really a
> project - it is just a category tag.  The point of a project is to
> coordinate things that actually NEED to be coordinated or at least
> benefit from it in some way.

It is not like a KDE, gnome or gstreamer project that has very tight
coordination needs, so we shouldn't judge those on the same grounds, but
from time to time, when a core library changes its API it needs a
project-wide coordination (plus a few extra revdep here and there that
you get to know over time). That's more how I see coordination there.
It is not as critical nor as frequent as it used to be but still
happens from time to time. Having a codec project goes against that
IMHO, we'd end up with a category tag where there's no relation between
any of the package except they're media libraries.

Alexis.



Re: [gentoo-dev] [RFC] Codec project

2020-06-12 Thread Rich Freeman
On Fri, Jun 12, 2020 at 10:33 AM Alexis Ballier  wrote:
>
> What about /j #gentoo-media, discuss, join the current projects, get a
> few things done (there is a lot of choice there ;) ), maybe orphan
> unmaintained players/viewers, or check if they are maintained and hand
> them to a specific maintainer, and then see about merging or splitting
> all those projects *after* gaining experience and knowledge about the
> peculiarities of some of those packages ?
>

Probably best to leave the details up to those doing the work, but I
would suggest this as a guideline:

Keep the scope reasonable.  If you expand the scope to a point where
90% of the project members don't care about 50% of the project scope,
then you're setting yourself up for a repeat of the past.  You want
80% of the project members to be interested in 80% of the packages
being maintained ideally.  Sure, there will be little niches that a
subset are more interested in, but you want to keep it focused around
a core where coordination makes sense.  You can have different roles
in the project but it should still be one project.

If most of the project members aren't talking to each other about most
of the things they're doing in the project, then it isn't really a
project - it is just a category tag.  The point of a project is to
coordinate things that actually NEED to be coordinated or at least
benefit from it in some way.

-- 
Rich



Re: [gentoo-dev] [RFC] Codec project

2020-06-12 Thread Alexis Ballier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 10 Jun 2020 20:25:20 +0200
Michał Górny  wrote:

> Hi,
> 
> Let's split this from [1] as I suppose having it in middle of
> high-noise 'up for grabs' might prevent some interested people from
> seeing it.
> 
> The general purpose of codec project [2] is to maintain core libraries
> for various multimedia format encoder/decoder libraries.  It's like
> gfx+sound+video except only for core packages and not every possible
> single viewer, player, editor, frontend...  

Not that I'm against the idea, but seeing the project has 3 members
already and none of them were part of the gfx+sound+video projects
AFAIK, I am wondering if this is the proper way to do it.

What about /j #gentoo-media, discuss, join the current projects, get a
few things done (there is a lot of choice there ;) ), maybe orphan
unmaintained players/viewers, or check if they are maintained and hand
them to a specific maintainer, and then see about merging or splitting
all those projects *after* gaining experience and knowledge about the
peculiarities of some of those packages ?

Speaking about sound, I am under the impression that the library,
or "codec" part, of those projects is far less lacking manpower than the
"leaf" part (players, frontends, etc.).

Alexis.
-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQSpOxaxaZikKNVNlsYOJUi7xgflrgUCXuOSHQAKCRAOJUi7xgfl
rp68AP9hzTRmZoDoderMZkLt5HsRCcfwemcVl2kvytPInVPvxQD+LnBcBOGaQy7Y
9iOhbi0fkwt9YBoq4rsBk3rzguHjvm0=
=f3JV
-END PGP SIGNATURE-


Re: [gentoo-dev] [RFC] Codec project

2020-06-11 Thread Aaron Bauman
On Thu, Jun 11, 2020 at 07:11:33AM -0500, Dale wrote:
> As a user, how about media?  Multimedia?  Or would those interfere with
> other packages?
> 
> I might add, regardless of name, will it be active enough to keep it
> alive or will it go the same as the last? 
> 
> Dale
> 
> :-)  :-) 

Please see the replies in the previous thread this was forked from.

Ultimately, this just "officially" gave other devs the right to touch
the impacted packages. Nothing has really changed...

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Codec project

2020-06-11 Thread Aaron Bauman
On Wed, Jun 10, 2020 at 08:25:20PM +0200, Michał Górny wrote:
> Hi,
> 
> Let's split this from [1] as I suppose having it in middle of high-noise 
> 'up for grabs' might prevent some interested people from seeing it.
> 
> The general purpose of codec project [2] is to maintain core libraries
> for various multimedia format encoder/decoder libraries.  It's like
> gfx+sound+video except only for core packages and not every possible
> single viewer, player, editor, frontend...  I believe that this specific
> focus make more sense than the wider projects, i.e. it is more likely
> than N people will actually co-maintain libraries used by many tools vs
> N people co-maintain 20 alternative sound players (when they are
> unlikely to use more than one at a time).
> 
> The main questions are:
> 
> 1. Should the project be focused on reference/most common
> implementations, or maybe more of them?  Say, giflib vs libnsgif.
> I think the latter library is specific to a few programs right now but
> if it gets more popular, it would fit.
>

I am not really sure that we *need* a project. I have seen many devs
takeover several packages... of those individuals, they are active and I
don't believe they would complain if others touched former @graphics
packages.

> 3. What about libraries implementing media-specific streaming protocols?

As stated above, I am not sure we need a project to maintain these. Of
course, it *would* be nice. Attempting to define something out of such
disparity seems frivolous, but I understand the intention.

Additionally, I am not advocating for the disbandment of all projects,
but simply those that lack impact. It was more an effort to show that
*most* individuals in said project were slacking, but would complain
when others attempted to assist.

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Codec project

2020-06-11 Thread Dale
Kent Fredric wrote:
> On Wed, 10 Jun 2020 20:25:20 +0200
> Michał Górny  wrote:
>
>> The general purpose of codec project [2] is to maintain core libraries
>> for various multimedia format encoder/decoder libraries.  It's like
>> gfx+sound+video except only for core packages and not every possible
>> single viewer, player, editor, frontend...  I believe that this specific
>> focus make more sense than the wider projects, i.e. it is more likely
>> than N people will actually co-maintain libraries used by many tools vs
>> N people co-maintain 20 alternative sound players (when they are
>> unlikely to use more than one at a time).
> Somehow I get the impression that "codec" as a scope is still too general.
>
> For instance, people well acquainted with audio codecs aren't
> necessarily well acquainted with video codecs, or image codecs.
>
> A package that only does audio-playback for instance, won't be of
> interest to somebody who predominantly cares about video playback.
>
> I'm not entirely against it as a concept as-is, I just suspect it will
> reiterate the previous problem.


As a user, how about media?  Multimedia?  Or would those interfere with
other packages?

I might add, regardless of name, will it be active enough to keep it
alive or will it go the same as the last? 

Dale

:-)  :-) 


Re: [gentoo-dev] [RFC] Codec project

2020-06-11 Thread Andreas K . Hüttel
> 1. Should the project be focused on reference/most common
> implementations, or maybe more of them?  Say, giflib vs libnsgif.
> I think the latter library is specific to a few programs right now but
> if it gets more popular, it would fit.

It's mostly a question of critical mass. To give an example from a different 
corner of Gentoo...

Initially net-libs/libtirpc was more of an obscurity, a more feature-complete 
replacement for code within glibc. Back then it didn't matter so much who 
maintained it.
In the meantime, the corresponding part of glibc has been phased out, and 
everyone is relying on libtirpc. So now it's important that it is well-
maintained, and it's taken care of by base@.

> 2. How many kinds of media should the project accept?  Audio, graphics,
> video seem pretty obvious.  Containers too.  libass makes sense as it is
> specifically for video subtitles.  Anything else?

Again, critical mass should be the main criterion. Things that are used by 
many different packages, with many different maintainers.

If a library is only used by LibreOffice, it makes more sence that it is 
maintained by office@. If a library is used exclusively via kde-frameworks, 
the same for kde@.

I wouldn't be too restrictive regarding the type of media.

> 3. What about libraries implementing media-specific streaming protocols?
> E.g. libshout, live...  I suppose the ones specific to voip would fall
> into voip project's domain instead.

Same arguments...

> 
> 
> [1]
> https://archives.gentoo.org/gentoo-dev/message/79073ab9c7cebd79fc12e897e110
> bc3c [2] https://wiki.gentoo.org/wiki/Project:Codec_project


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Codec project

2020-06-10 Thread Kent Fredric
On Wed, 10 Jun 2020 20:25:20 +0200
Michał Górny  wrote:

> The general purpose of codec project [2] is to maintain core libraries
> for various multimedia format encoder/decoder libraries.  It's like
> gfx+sound+video except only for core packages and not every possible
> single viewer, player, editor, frontend...  I believe that this specific
> focus make more sense than the wider projects, i.e. it is more likely
> than N people will actually co-maintain libraries used by many tools vs
> N people co-maintain 20 alternative sound players (when they are
> unlikely to use more than one at a time).

Somehow I get the impression that "codec" as a scope is still too general.

For instance, people well acquainted with audio codecs aren't
necessarily well acquainted with video codecs, or image codecs.

A package that only does audio-playback for instance, won't be of
interest to somebody who predominantly cares about video playback.

I'm not entirely against it as a concept as-is, I just suspect it will
reiterate the previous problem.


pgpt1MEfgzDTX.pgp
Description: OpenPGP digital signature