Le 17 août 2024 19:32:00 GMT+03:00, Michael Niedermayer <mich...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
