> > 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 _______________________________________________ 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".
