| Message ID | 20240815073307.2441983-1-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] MAINTAINERS: Add more fields based on the linux kernel MAINTAINERs | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
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 > ============
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 [...]
Quoting Michael Niedermayer (2024-08-15 09:33:07) > 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 I agree with Rémi that we are way too small to need Linux-style subsystem delegation. I do not see who this is for and what actual problems it is supposed to address.
On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-08-15 09:33:07) > > 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 > > I agree with Rémi that we are way too small to need Linux-style > subsystem delegation. Lets see, lets pick last month, july, in july 2024 we had 1456 messages on ffmpeg-devel july 2023 we had 1493, july 2022 we had 1221, july 2021 we had 953, july 2020 we had 1668 july 2019 we had 1316 july 2018 we had 974 july 2016 we had 1139 july 2014 we had 1183 july 2012 we had 1901 july 2010 we had 2391 Does this look to you like we are growing or that there is some limitation ? (also i could quote both Paul and Kostya about saying that the project dying) lets compare to LKML which used this proposed MAINTAINER system july 2004 had 6435 july 2003 had 7558 july 2002 had 6194 july 2001 had 2502 july 2000 had 4879 july 1999 had 4837 july 1998 had 4303 july 1997 had 2590 july 1996 had 2053 so i downloaded linux 2.1 from 1996 and looked at its MAINTAINER file P: Person M: Mail patches to L: Mailing list that is relevant to this area W: Web-page with status/info S: Status, one of the following: ... But lets see how many seperate lists where already there in 1996 grep 'L:' MAINTAINERS | sort | uniq -c 1 L: digiboard@list.fuller.edu 1 L: isdn4linux@hub-wue.franken.de 2 L: linux-eata@i-connect.net, linux-scsi@vger.rutgers.edu 2 L: linux-hams@vger.rutgers.edu 1 L: linux-ipx@vger.rutgers.edu [will change] 14 L: linux-kernel@vger.rutgers.edu 1 L: linux-laptop@vger.rutgers.edu 9 L: linux-net@vger.rutgers.edu 1 L: linux-ppp@vger.rutgers.edu 4 L: linux-scsi@vger.rutgers.edu 1 L: linux-smp@vger.rutgers.edu 1 L: linux-tape@vger.rutgers.edu 1 L: linware@sh.cvut.cz 1 L: Mailing list that is relevant to this area 1 L: samba@listproc.anu.edu.au 1 L: [Someone fill in the netatalk list here] 1 L: sparclinux@vger.rutgers.edu So here we established the fact that FFmpeg definitly reached the size at which the kernel had "subsystems" even though the word occured only once in MAINTAINER in 2.1 > I do not see who this is for and what actual > problems it is supposed to address. Many problems or many aspects of the same problem(s) Its fundamental human nature that people want to be free and work on their things without others interfering too much. They want to create things they feel proud of. Just think of it this way maybe, If you take 100 skilled artists and let each work on their own you will get 100 art pieces many will be impressive. OTOH if you put these 100 artists in the same group you will get one art piece and many artists who want to leave. Do you see maybe the relation to FFmpeg and people leaving ? You could also make this example with cooks. 100 cooks make 100 wonderfull dishes when they can work independantly. But if they are in the same kitchen and argue and demand changes from each other, the result will not be wonderfull nor will the cooks be satisfied with their own work, eventually some will leave You dont see this because you where not hit by this yourself in a way that bothers you. Just as a unrelated, side note: Also i think VDD is making it worse. It increases the gap between everyone who comes to VDD and everyone who doesnt come to VDD. And i think it makes it also harder for the people who come to VDD (who grow closer together) to see the problem outside that group (and iam not joking here, i have received mails from people saying they would support a fork, ...) Also this patch doesnt split FFmpeg into subsystems it just allows people a richer set of options in how to specify how and where each part is maintained. (maybe noone will even use this) This is just a small step in improving things and really it sadens me that this is taken as something controversal. thx [...]
Hi, Le 15 août 2024 14:30:38 GMT+03:00, Michael Niedermayer <michael@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@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!
Quoting Michael Niedermayer (2024-08-15 22:49:03) > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-08-15 09:33:07) > > > 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 > > > > I agree with Rémi that we are way too small to need Linux-style > > subsystem delegation. > > Lets see, lets pick last month, july, in > july 2024 we had 1456 messages on ffmpeg-devel > july 2023 we had 1493, > july 2022 we had 1221, > july 2021 we had 953, > july 2020 we had 1668 > july 2019 we had 1316 > july 2018 we had 974 > july 2016 we had 1139 > july 2014 we had 1183 > july 2012 we had 1901 > july 2010 we had 2391 > > Does this look to you like we are growing or that there is some limitation ? > (also i could quote both Paul and Kostya about saying that the project dying) WTF is that supposed to mean and how is it relevant to this thread? > > > I do not see who this is for and what actual > > problems it is supposed to address. > > Many problems or many aspects of the same problem(s) > > Its fundamental human nature that people want to be free and work on their > things without others interfering too much. They want to create > things they feel proud of. > > Just think of it this way maybe, If you take 100 skilled artists and let > each work on their own you will get 100 art pieces many will be impressive. > OTOH if you put these 100 artists in the same group you will get one art piece > and many artists who want to leave. > Do you see maybe the relation to FFmpeg and people leaving ? > > You could also make this example with cooks. 100 cooks make 100 wonderfull dishes > when they can work independantly. But if they are in the same kitchen and argue > and demand changes from each other, the result will not be wonderfull nor will > the cooks be satisfied with their own work, eventually some will leave > > You dont see this because you where not hit by this yourself in a way > that bothers you. This is not an answer, this is a parable capped off with an ad hominem. > Just as a unrelated, side note: > Also i think VDD is making it worse. It increases the gap between everyone > who comes to VDD and everyone who doesnt come to VDD. And i think it makes > it also harder for the people who come to VDD (who grow closer together) > to see the problem outside that group Are you seriously saying that developers should not socialize because then other developers who CHOOSE not to socialize do not get the benefits of socialization? I'd love to say it is the most insane ffmpeg-related thing I've seen recently, but sadly it only takes second place. > This is just a small step in improving things and really it sadens me > that this is taken as something controversal. In other words, "I am sad that people disagree with me, therefore people should not disagree with me". This is a textbook attempt at emotional manipulation, AKA "appeal to emotion". This is a technical project, you should present technical arguments that support your position.
Le 15 août 2024 23:49:03 GMT+03:00, Michael Niedermayer <michael@niedermayer.cc> a écrit : (...) >So here we established the fact that FFmpeg definitly reached the size >at which the kernel had "subsystems" even though the word occured only >once in MAINTAINER in 2.1 I think this is more a question of code size and code churn, and I don't see any data to support that FFmpeg has reached (or not) the point that its development should be split into subsystems. (...) >Just think of it this way maybe, If you take 100 skilled artists and let >each work on their own you will get 100 art pieces many will be impressive. >OTOH if you put these 100 artists in the same group you will get one art piece >and many artists who want to leave. >Do you see maybe the relation to FFmpeg and people leaving ? Bluntly, no. I believe that the main reasons why people leave are: 1) Hobbyists finished, or got bored with, whatever they were fiddling with, and moved on to something else. 2) Professionals were compensated to work on FFmpeg and no longer are, due to project completion, change of business direction, or change of job. 3) As the project has matured, the "easy" parts are already implemented (multimedia as a whole is a mature field now), the learning curve is ever steeper, the coding standards and constraints are ever more taxing, etc. This discourages old hobbyists and prospective new members alike. 4) The community is particularly toxic by contemporary standards (IMO, due to CC inaction). The first 3 points are mostly out of our hands. And none of those 4 points are addressed by splitting up the development process into subsystems.
Hi On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-08-15 22:49:03) > > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2024-08-15 09:33:07) > > > > 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 > > > > > > I agree with Rémi that we are way too small to need Linux-style > > > subsystem delegation. > > > > Lets see, lets pick last month, july, in > > july 2024 we had 1456 messages on ffmpeg-devel > > july 2023 we had 1493, > > july 2022 we had 1221, > > july 2021 we had 953, > > july 2020 we had 1668 > > july 2019 we had 1316 > > july 2018 we had 974 > > july 2016 we had 1139 > > july 2014 we had 1183 > > july 2012 we had 1901 > > july 2010 we had 2391 > > > > Does this look to you like we are growing or that there is some limitation ? > > (also i could quote both Paul and Kostya about saying that the project dying) > > WTF is that supposed to mean and how is it relevant to this thread? You claimed "we are way too small to need Linux-style subsystem delegation." What i showed is that we are stagnant and not growing, and that projects with Linux-style subsystem delegation do not have this issue at this size. Paul and Kostyas point of view is a step further, that we are declining (for whatever reason) Its a fact of life, if things dont grow they tend to decline. To be perfectly balanced at the same size over long time there must be something that pushes it to that size. one can side by side compare projects that grow and are stagnant. I claim that for us its the closed-ness of our development model thats the cause. The need that every codec, every format, every filter must be in one repository and that every change to it must pass through one gate. I claimed this many times over many years, this is not new. I suggested many time that a plugin architecture and or a linux like development model would solve this > > > > > > I do not see who this is for and what actual > > > problems it is supposed to address. > > > > Many problems or many aspects of the same problem(s) > > > > Its fundamental human nature that people want to be free and work on their > > things without others interfering too much. They want to create > > things they feel proud of. > > > > Just think of it this way maybe, If you take 100 skilled artists and let > > each work on their own you will get 100 art pieces many will be impressive. > > OTOH if you put these 100 artists in the same group you will get one art piece > > and many artists who want to leave. > > Do you see maybe the relation to FFmpeg and people leaving ? > > > > You could also make this example with cooks. 100 cooks make 100 wonderfull dishes > > when they can work independantly. But if they are in the same kitchen and argue > > and demand changes from each other, the result will not be wonderfull nor will > > the cooks be satisfied with their own work, eventually some will leave > > > > You dont see this because you where not hit by this yourself in a way > > that bothers you. > > This is not an answer, this is a parable capped off with an ad hominem. why do you read this as if it was a personal attack? You yourself just said "I do not see who this is for and what actual problems it is supposed to address." And now if i speculate why as in "you dont see this because ..." is a personal attack ? If you do see the problem we dont need to discuss it. OTOH if you do not see key developers leaving or dont see their pain or dont see that they are happier when they can develop their code outside. Then we should discuss this, maybe iam wrong, maybe you will see the relation, maybe something entirely different will happen. This was not meant as an attack, it was meant as a discussion to resolve teh difference in our points of view. > > > Just as a unrelated, side note: > > Also i think VDD is making it worse. It increases the gap between everyone > > who comes to VDD and everyone who doesnt come to VDD. And i think it makes > > it also harder for the people who come to VDD (who grow closer together) > > to see the problem outside that group > > Are you seriously saying that developers should not socialize > because then other developers who CHOOSE not to socialize do not get the > benefits of socialization? no, i did not say that, nor is that even close to what i meant. why do you read my email in such a negative way ?! thx [...]
On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-08-15 22:49:03) > > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2024-08-15 09:33:07) [...] > > This is just a small step in improving things and really it sadens me > > that this is taken as something controversal. > > In other words, "I am sad that people disagree with me, therefore people > should not disagree with me". > This is a textbook attempt at emotional manipulation, AKA "appeal to > emotion". Thats a straw man fallacy. You word my position in a way that is not my position and then attack that Iam sad that FFmpeg started with a development model that would hit a scalability issue. And that i failed to change that later. Iam sad about my failure here Iam sad that the development model is kind of locked down, that maintaince outside isnt possible. And that any attempt to change that is blocked Iam not sad anyone disagrees with me Also theres nothing being split up. We have already people maintaining code outside. For example Paul in librempeg If one suggests to redo his work and "kill him off", instead of acknowledging that he maintains some parts of the codebase outside. Thats not a good solution IMHO, even though we likely will succeed if we try that. Here we do have again the scalability thing. look inward, redo others work, deny their existance or acknowledge their work and find a way to combine the work and move forward and grow This change to MAINTAINERs is just a small first step. The next step may be that we or I would talk with paul and see what exactly his oppinion and preferrance is. I cannot for example suggest to paul that he could maintain his code outside of ffmpeg and be paid for that IF here people already oppose to the idea of even allowing that at a syntax level in MAINTAINERs also of course payment requires STF & SPI & future community consensus. We are many steps away from this still. Iam in some sense here probing what the team would be ok with and what not and it makes me sad if outside maintaince is not an option. The fewer options we have the less likely it is that we can find an agreement with Paul. Of course others might want to use this too. thx [...]
Le 17 août 2024 19:32:00 GMT+03:00, Michael Niedermayer <michael@niedermayer.cc> a écrit : >Hi > >On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote: >> Quoting Michael Niedermayer (2024-08-15 22:49:03) >> > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: >> > > Quoting Michael Niedermayer (2024-08-15 09:33:07) >> > > > 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 >> > > >> > > I agree with Rémi that we are way too small to need Linux-style >> > > subsystem delegation. >> > >> > Lets see, lets pick last month, july, in >> > july 2024 we had 1456 messages on ffmpeg-devel >> > july 2023 we had 1493, >> > july 2022 we had 1221, >> > july 2021 we had 953, >> > july 2020 we had 1668 >> > july 2019 we had 1316 >> > july 2018 we had 974 >> > july 2016 we had 1139 >> > july 2014 we had 1183 >> > july 2012 we had 1901 >> > july 2010 we had 2391 >> > >> > Does this look to you like we are growing or that there is some limitation ? >> > (also i could quote both Paul and Kostya about saying that the project dying) >> >> WTF is that supposed to mean and how is it relevant to this thread? > >You claimed "we are way too small to need Linux-style subsystem delegation." >What i showed is that we are stagnant and not growing, and that projects with >Linux-style subsystem delegation do not have this issue at this size. You're confusing correlation and causation. FFmpeg is not stagnant *because* it does not have subsystems and non-fast-forward merges. The vast majority of OSS projects do not have subsystems (in the Linux sense) regardless of whether they are stagnant, dwindling or expanding. Linux-like development is but a mean to scale up. It is completely senseless to adopt that methodology in a project that does *not* have a major problem with scaling. It just brings more problems and solves almost none. In other words, you're (figuratively) putting the cart before the horse here. >Paul and Kostyas point of view is a step further, that we are declining (for whatever reason) Subsystem delegation will not make things any better. The reasons why Paul forked are not addressed in any meaningful way by breaking FFmpeg down into Git subsystems. I'm oversimplifying but we have 3 factions now: - The FFboring faction wants to stick strictly to the current scope, do maintainance and immediately adjacent new features, for the benefit of existing downstreams and the `ffmpeg` CLI. - The Make FFmpeg Great Again faction wants to merge whatever experiments any committer works at, without the shackles of stability, FATE, the review process, etc, going back to how FFmpeg originally was (or how they idealise it), - the Neither-Nor faction who's trying to find an impossible middle ground and ends up mostly (but not fully) aligning with FFboring by default. Unfortunately I don't think this is tenable in the long run because the first two factions are really pushing in contradictory directions, that are not really amenable to compromised. The fact that Paul forked seems to confirm this. But regardless, Linux-style subsystems are *not* going to help here at all. >I claimed this many times over many years, this is not new. I suggested >many time that a plugin architecture and or a linux like development >model would solve this A plugin architecture is completely orthogonal to development methodology (and I am not personally against it). And in fact, I am not against Linux-style development per se, but FFmpeg does not currently have the scale to justify the additional *overhead* thereof. >why do you read my email in such a negative way ?! Because of how you worded it. I'm with Anton on this one.
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 ============
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(-)