On 21/01/2025 11:51, Niklas Haas wrote: > On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer > <mich...@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 _______________________________________________ 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".
