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

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

[Michael Niedermayer]

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.
It allows listing a separate tree where development happens, and against which
thus patches should be done.

Overall this gives us/the people many more options on how to maintain their stuff

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 MAINTAINERS | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6ce8bc86393..44efd9bc00a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6,10 +6,26 @@ FFmpeg code.
 
 Please try to keep entries where you are the maintainer up to date!
 
-Names in () mean that the maintainer currently has no time to maintain the code.
+*Status*, one of the following:
+[X] Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that.
+[0] No current maintainer [but maybe you could take the role as you write your new code].
+[1] It has a maintainer but they don't have time to do much other than throw the odd patch in.
+[2] Someone actually looks after it.
+
 A (CC <address>) after the name means that the maintainer prefers to be CC-ed on
 patches and related discussions.
 
+(L <address>) *Mailing list* that is relevant to this area
+(W <aadress>) *Web-page* with status/info
+(B <address>) URI for where to file *bugs*. A web-page with detailed bug
+              filing info, a direct bug tracker link, or a mailto: URI.
+(P <address>) *Subsystem Profile* document for more details submitting
+              patches to the given subsystem. This is either an in-tree file,
+              or a URI. See Documentation/maintainer/maintainer-entry-profile.rst
+              for details.
+(T <address>) *SCM* tree type and location.
+              Type is one of: git, hg, quilt, stgit, topgit
+
 
 Applications
 ============
-- 
2.45.2

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Rémi Denis-Courmont]

Le 15 août 2024 10:33:07 GMT+03:00, Michael Niedermayer <michael@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.

>It allows listing a separate tree where development happens, and against which
>thus patches should be done.
>
>Overall this gives us/the people many more options on how to maintain their stuff
>
>Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
>---
> MAINTAINERS | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 6ce8bc86393..44efd9bc00a 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -6,10 +6,26 @@ FFmpeg code.
> 
> Please try to keep entries where you are the maintainer up to date!
> 
>-Names in () mean that the maintainer currently has no time to maintain the code.
>+*Status*, one of the following:
>+[X] Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that.
>+[0] No current maintainer [but maybe you could take the role as you write your new code].
>+[1] It has a maintainer but they don't have time to do much other than throw the odd patch in.
>+[2] Someone actually looks after it.
>+
> A (CC <address>) after the name means that the maintainer prefers to be CC-ed on
> patches and related discussions.
> 
>+(L <address>) *Mailing list* that is relevant to this area
>+(W <aadress>) *Web-page* with status/info
>+(B <address>) URI for where to file *bugs*. A web-page with detailed bug
>+              filing info, a direct bug tracker link, or a mailto: URI.
>+(P <address>) *Subsystem Profile* document for more details submitting
>+              patches to the given subsystem. This is either an in-tree file,
>+              or a URI. See Documentation/maintainer/maintainer-entry-profile.rst
>+              for details.
>+(T <address>) *SCM* tree type and location.
>+              Type is one of: git, hg, quilt, stgit, topgit
>+
> 
> Applications
> ============
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3391 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".