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

[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.  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.

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