[FFmpeg-devel] [RFC] 5 year plan & Inovation
Zhao Zhili
quinkblack at foxmail.com
Sun May 5 03:59:51 EEST 2024
> 在 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".
More information about the ffmpeg-devel
mailing list