Michael Niedermayer (12022-07-25):
> I think many if us, myself included have had un-fun periods in ffmpeg.
> This on its own is already bad and we should strive to make project
> contributions more fun to all.

In my opinion, it would require at least two things:

- That the members of the Community Committee step in more proactively
  in budding conflicts. And take sides: not “both be nice” but “you
  started it, shut up”.

- A person or group of person capable of deciding ahead if a change that
  will affect every body is worth investing time implementing it.

> If we add a XML parser to FFmpeg. Such a thing would be used by several
> bits and we need to ensure it has redundant maintainership.
> So i think a xml parser needs broad support by developers otherwise we
> run the risk that if it has a single maintainer only and that maintainer
> stops maintaining it that could be annoying to more than just the parser
> itself.
> I cannot remember exactly without re-reading the old thread what the issues
> people had with the xml parser. If it was some component of it or in general.
> But i think its mostly a question if theres more than one person who wants
> to maintain it.

There is nothing to re-read:

https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/thread.html#296107

Nobody answered. Even to send files to make sure they would be
supported.

We would need reliable maintainers, you are right. But right now, we
rely on libxml2, and that is not ideal: it is not a standard library on
non-Linux systems, and even if it seems better nowadays, it used to be a
“security issue of the week” kind of library.

> If you work on libavfilter, noone will snatch it from you. If you
> dont work on it, eventually someone else will attempt to take over and
> push libavfilter in the direction he feels best which may or may not 
> match what you want.

I will try to motivate myself to advance the FATE coverage, which is the
blocking issue.

Thanks,

-- 
  Nicolas George