[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Aidan]

>
> On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote:
> > I submitted a patch for a TTML decoder because I thought it would be
> great.
> > It was completely ignored.
> Please ping the patch or send a new one
>
I should probably redo my patch at this point. It's a year old. It's kind
of a complicated patch because TTML is a huge format.
It would be great to have a TTML decoder existing in FFmpeg. I guess if I
do submit one, I will be more annoying about pinging.
There is nowhere saying bumping every few weeks is ok. I read all
documentation related to sending a patch.

> > If my patch was seriously bad, then fine. But seriously *no one cared*.

I think contribution management is a serious issue here.

What happens when you send a patch is that if you're lucky someone
> will be interested and put some effort to review and eventually get it
> pushed, which depending on several factors might require several
> interactions.
>
The only few times I've been completely ignored while trying to contribute
to FLOSS software was software that ended up being forked with a better
alternative because it was run by shitty people. However I am not saying
that FFmpeg is that way.

> Sometimes contributors are side-tracked or frustrated and the review
> process is interrupted. Sometimes the reviewer won't reply, and the
> review also might be stuck (in this case you might want to ping the
> patch).
>
> Sometimes there is no qualified or interested developer around, or
> maybe those ones are busy with other things (and it's easy to miss
> a patch, especially if you don't check emails since a few days and you
> got hundreds of backlog emails).
>
> In general, this is done on a best effort basis (read as: most
> developers are volunteers and they might have job/families/stuff to
> tend to), there is no guarantee that a patch might be reviewed in a
> timely fashion.
>
> This is not a problem specific with FFmpeg, but in general with most
> FLOSS projects.
>
> Probably we should find ways to fund such activites, so that a
> developer can spend more time on reviewing work, but this comes with
> other risks/issues (since managing money is also complex of potential
> tensions in a mostly volunteering-based project)

Yep, you are completely right. I cannot say you aren't right.

>

It's also very difficult to track the sent patches, and that's why
> having a Pull-Request process a-la github has been proposed several
> times; we cannot switch to github for several reasons (licensing and
> affilitation issues with platform owner) and handling your own gitlab
> is costly and we lack volunteers at the moment.

I saw that conversation. It just sounds like over-complication for this
project. Email can be okay if done right. Not user-friendly but if its
documented good then its mostly fine.

>
>
We are using patchwork to mitigate the tracking issue:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/
>
> but that's not really providing an effective workflow.
>
> Personally I find the status tracking confusing, e.g.:
>
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate=
>
> I cannot easily figure out what was integrated and what not.
>
Funny to see my old patch on that list.


Kind regards,
Aidan / TheDaChicken