> 在 2024年5月5日，上午5:51，epira...@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@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > 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". _______________________________________________ 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".
