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

Michael Niedermayer michael at niedermayer.cc
Sat Aug 17 19:32:00 EEST 2024


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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240817/e68da205/attachment.sig>


More information about the ffmpeg-devel mailing list