[FFmpeg-devel] Regarding Git Tooling

James Almer jamrial at gmail.com
Tue Jan 21 18:37:27 EET 2025


On 1/21/2025 9:04 AM, Niklas Haas wrote:
> On Mon, 20 Jan 2025 14:39:29 -0600 Marth64 <marth64 at proxyid.net> wrote:
>> Hello, in the context of a GA member,
>>
>> I think there is general interest in modernizing technical tooling
>> specifically regarding ML/patch workflow vs. integrated git solution.
>> Both have their merits. I think what we have today is optimized for
>> some but cumbersome for many. Like shopping for a drill, it is good to
>> step back from time to time and ensure we have the right tools.
>>
>> I think the problem statement of productivity being impacted from
>> outgrowing the current tooling is different from who is hosting it.
>>
>> These are some options I noticed interest in (in no particular order):
>> - Forgejo
>> - GitLab
>> - Mailing List/Patch Workflow (current solution)
> 
> Since our last discussion at VDD, I have come to prefer Forgejo over GitLab
> and would be in favor of hosting an instance on ffmpeg.org.
> 
> What are the current barriers to doing this. Michael, since you said that you
> are in favor iff the community agrees with it, should we start a GA vote on
> the matter?
> 
> Can Timo set it up and maintain it for us? If not, I can also volunteer myself
> to do it.
> 
>>
>> If we evaluate this as choosing a software appliance and put aside
>> "who is the host" I think we can have a good discussion. There could
>> be value in coming to consensus on one step, then moving on to the
>> next.
>>
>> The goal is not to spin around on which tool is better but I am wondering,
>> - What other options would the community consider and any relevant pros/cons?
> 
> One pro about ForgeJo is that unlike most of its competitors, it is a community
> run project with a democratic governance model, a high degree of transparency
> on infrastructure and process, and a commitment to fully open source software
> (GPLv3+).

So, it works. The only thing we're missing is people to stop being 
aggressive to each other. And for that, the CC should act and be swift.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20250121/9c482dcb/attachment.sig>


More information about the ffmpeg-devel mailing list