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

[Zhao Zhili]

> 在 2024年5月5日，上午5:51，epirat07 at gmail.com 写道：
> 
> 
> 
>> On 4 May 2024, at 23:25, Andrew Sayers wrote:
>> 
>>> On Sat, May 04, 2024 at 09:28:03PM +0200, Michael Niedermayer wrote:
>>> Hi
>>> 
>>>> On Fri, May 03, 2024 at 03:45:20PM +0000, Cosmin Stejerean via ffmpeg-devel wrote:
>>> [...]
>>>> What doesn't exist (yet) is a way to keep people on the exact email based workflow
>>>> we currently have, and have bi-directional sync with something like github or gitlab.
>>>> Such a thing could probably be built, but it might be worth first trying to see if those
>>>> that insist on sticking with the CLI can use one of the existing CLI based workflows.
>>> 
>>> Such a thing could be quite useful to many more projects than just ffmpeg.
>>> There are many older projects that use ML based workflows.
>>> 
>>> I imagine STF might be willing to fund such a thing if it is technically
>>> feasable. As the goal of STF is about maintainance. And bridging the gap
>>> between old ML and new browser based workflows allowing developers who
>>> prefer to work through their web browser to do so.
>>> 
>>> also, we need to find maintaince related projects worth minimum 150k €
>>> for 2025 for STF.
>>> We cant do many of the things we do in 2024 for STF again as they where
>>> one time things and STF doesnt like sponsoring adding new features.
>>> 
>>> thx
>> 
>> It seems like the strongest argument for sticking with the ML is from
>> experienced maintainers who don't want to jeopardise their existing
>> workflow; while the strongest argument for switching is from people
>> itching to try out new workflows.

It’s not “try out new workflows”, but current workflow is inefficient and unbearable for some of us.

>> So how about this for a plan...
>> 
>> Make a repo on SourceHut, not necessarily for FFmpeg itself but for
>> automated review tools (running fate tests, checking C11 compliance
>> etc.).  Their CI/CD system automatically runs those tests on every
>> patch, then we manually forward genuine issues to the ML.  That would
>> let experimenters show off new things, and would let maintainers
>> think through what their workflow would look like in a mixed
>> environment.  Then when we've got enough evidence to make a long-term
>> plan, we can wind the repo down without too much fuss.
> 
> I hardly see how SourceHut would improve much of any of the actual
> struggles we talked about in this thread tbh…
> 
> FWIW what most people are desiring is better review workflow/tooling
> than a mail client can not offer (easily) and making it easier for
> people to contribute by simply pushing a branch to their fork
> which is for better or worse what a lot of people are familiar with
> from GitHub.
> 
> Both of which is nothing SourceHut offers, to my knowledge.
> 
> So rather than spend efforts on something that only marginally improves
> upon what is currently used it would IMHO be way more useful to evaluate
> something like GitLab or Gitea/Forgejo.

+1

> 
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".