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

[Rémi Denis-Courmont]

Hi,

Le 15 août 2024 14:30:38 GMT+03:00, Michael Niedermayer <michael at niedermayer.cc> a écrit :
>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

Your goal is not to break it up, but I am not questioning your motivations here. I am questioning the suitability of the proposal to the stated problem, and the unintended consequences thereof.

Splitting technical discussions into distinct topical mailing lists is very much breaking the project down 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 ?

We already have problems with upstream bugs getting lost in downstream distro or app bug trackers, and downstream bugs getting lost in our upstream Trac.

Do you want to add another dimension to that problem? Who is going to triage and forward bug reports between main Trac and subsystem issue trackers?

I'm all for triaging bugs by rightful component or subsystem, but that only really works with a centralised bug tracker. It would more or less work if main and all subsystems used the same Gitlab instance: you can move bugs between projects. But it won't work if we keep Trac because we can't settle for
 something else.

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

That is not possible if people submit merge requests to a web UI. At best you'll get one email notifying that there's a new or updated patch set, with a URL where to view it.

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

So how would patches move from web forge subsystem projects to main git? Are we blindly trusting subsystem maintainers to merge? Or does the TC have to do it?

How do we deal with patch sets straddling more than one subsystem? You can Cc mailing lists, but you can't Cc a web forge project. Some recent sets touched x86, AArch64, checkasm and VVC/H.266 all at once!