[FFmpeg-devel] [PATCH] MAINTAINERS: Add more fields based on the linux kernel MAINTAINERs

[Michael Niedermayer]

Hi

On Thu, Aug 15, 2024 at 11:24:31AM +0300, Rémi Denis-Courmont wrote:
> 
> 
> Le 15 août 2024 10:33:07 GMT+03:00, Michael Niedermayer <michael at niedermayer.cc> a écrit :
> >Text was stolen from the linux kernel
> >This is thus identical to the kernel just a different more compact format.
> >I am very happy also to switch the file entirely to the format of the linux kernel maintainer list
> >if people prefer
> >
> >This allows tracking the status of each sub system, if it needs new blood or not
> >
> >It allows people to specify a separate webpage / document describing the subsystem
> >It allows people to ask for bug reports to be mailed to them instead of just
> >sent to trac.
> >It allows listing things like gitlab or github or anything else where to
> >submit patches. This could be used both for testing new patch submission systems
> >as well as permanently honoring the preferance of the developers maintaining a
> >subsystem.
> 
> We don't really have a process for managing subsystems, and however large FFmpeg is (compared to most OSS projects), it's only about as active as a single active Linux subsystem.
> 
> If people feel that Ffmpeg-devel has too much traffic then I'll gladly move RISC-V to code.videolan.org. But I haven't really noticed anybody making such complaint.
> 
> I don't think we should break FFmpeg development up into silos unless it's become unmanageably large otherwise.

Nothing in this patch suggests to break FFmpeg development up into silos

But how many developers can follow the mailing list fully ?

how many developers can follow trac and notice if their code has a bug reported against it ?
I certainly am failing to follow trac at that level, and i would appreciate if people would
CC me if they open a bug related to code i maintain or a change i pushed.
It seems like a good idea if i could specify that i prefer that somewhere

Also some people do develop code outside the main ffmpeg git master. Sometimes thats
temporary sometimes permanent. It could make sense if patches get sent against these
to reduce rebasing work.
IMO patches should always still be sent to ffmpeg-devel.

The idea is not to break anything up, its really the opposit, to glue things
together where they are broken up for social or technical reasons.
An example could be that someone, who maintains code outside git master already
now, could list that fact in MAINTAINERs.

Also there are different preferrances on how to submit patches, some people want
a switch to a webapp based system, some people oppose this. This change to
MAINTAINERs would allow both to have what they prefer. It doesnt mean thats
what we will do, just that the file would allow to represent that state.

Also last but not least, I ommited "C: URI for *chat* protocol, server and channel where developers"
from the kernel MAINTAINERs, for the very reason not to create silos. we have our
communication channels and we should not split these.
but at the same time we have things like ffmpeg-security and ffmpeg-devel-owner
as seperate entities for the maintaince for the respective "subsystem" arguably
"subsystem" is maybe an ill choosen term here

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240815/508058af/attachment.sig>