On Tue, 21 Jan 2025 18:55:05 +0100 Frank Plowman <p...@frankplowman.com> wrote: > 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.
+1 > > 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 In the worst case of zero interoperability, this will simply require maintainers to check both the forge *and* the ML for patches for a given period of time. And given that one can simply set up e-mail notifications for the web forge, the overhead of this is not particularly high. I don't see the added value of wasting time on implementing a temporary solution for a non-existent or marginal problem. > 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". _______________________________________________ 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".
