Re: [gentoo-dev] [RFC] Codec project
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
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
-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&video, 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
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
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
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
> 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
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
[gentoo-dev] [RFC] Codec project
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. 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? 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. [1] https://archives.gentoo.org/gentoo-dev/message/79073ab9c7cebd79fc12e897e110bc3c [2] https://wiki.gentoo.org/wiki/Project:Codec_project -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
