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