[FFmpeg-devel] Regarding Git Tooling

[Frank Plowman]

On 21/01/2025 11:51, Niklas Haas wrote:
> On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer <michael at niedermayer.cc> wrote:
>> On Tue, Jan 21, 2025 at 02:26:24AM +0100, Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Mon, Jan 20, 2025 at 02:39:29PM -0600, Marth64 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)
>>>>
>>>> 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?
>>>
>>> I dont know why the options are exclusive. One can add a Forgejo on ffmpeg.org
>>> but leave the Mailing List/Patch Workflow in place for cases where the
>>> maintainer or patch author prefers a ML workflow.
>>>
>>> I mean just add an option and see what happens
>>> Who uses it ?
>>> do people submit patches to it ?
>>> do people enjoy working with it ?
>>> do people hate working with it ?
>>
>> also to elaborate because i have this feeling everything i say lately is
>> misinterpreted
>>
>> if we have Forgejo + ML we can still decide to drop one later and use only
>> one.
> 
> I think that this makes sense during a planned transition period, to give
> everybody enough time to settle into the new system, but it should IMO only be
> done with an explicit timeline for when ML submissions will be halted.
> 

+1, although I would perhaps call it a "trial period" rather than a
"transition period".  I think if there is consensus that the forge is
not working when the period comes to a close, then we should not feel
obligated to transition to it.  Instead, we might choose to extend the
period or to return to the ML workflow.  I might even go one step
further and suggest that, if we are to undertake a vote on the
transition, we vote at the end of the trial period.  This way we will
vote with some experience using the forge, rather than speculatively.

In either case, in my mind the duration of such a period is closely
related to how difficult it will be to implement interoperability
between the two systems.  If the period is to be short, we may be
willing to compromise on non-interoperability of some non-essential
features in the interest of avoiding somebody sinking time on a
temporary solution.  On the other hand, if the period is to be long then
we might have more stringent requirements on interoperability.  This
goes the other way also: if investigation indicates it will be difficult
to implement interoperability of some features, then perhaps we should
opt for a shorter period.  There has been some discussion along these
lines already, but if we are to go with a finite transition period, then
I think we need to establish:
* What duration we would like for a transition period.
* A list of features which we would like to interoperate between the
  forge and ML, ideally sorted with some sort of priority.
* How difficult we expect it to be to implement interoperability of the
  aforementioned features.

I also think we need to have a clear plan in place and roles delegated
regarding spam.  Who is responsible and given the necessary permissions
to remove spam?  Are there automated tools we can use to help us reduce
spam?  What is our plan in the case we are overwhelmed with spam?

-- 
Frank