From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id A89F14B577 for ; Tue, 21 Jan 2025 18:21:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9743068B722; Tue, 21 Jan 2025 20:21:00 +0200 (EET) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 548C368B615 for ; Tue, 21 Jan 2025 20:20:53 +0200 (EET) Received: from haasn.dev (unknown [10.30.1.1]) by haasn.dev (Postfix) with ESMTP id 0AC6E47E92 for ; Tue, 21 Jan 2025 19:20:53 +0100 (CET) Date: Tue, 21 Jan 2025 19:20:52 +0100 Message-ID: <20250121192052.GD97472@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: <6f779552-5251-472b-9551-dcfc9b20b82d@frankplowman.com> References: <20250121012624.GC4991@pb2> <20250121024106.GF4991@pb2> <20250121125144.GB9168@haasn.xyz> <6f779552-5251-472b-9551-dcfc9b20b82d@frankplowman.com> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] Regarding Git Tooling X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Tue, 21 Jan 2025 18:55:05 +0100 Frank Plowman wrote: > On 21/01/2025 11:51, Niklas Haas wrote: > > On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer 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-request@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-request@ffmpeg.org with subject "unsubscribe".