From: Niklas Haas <ffmpeg@haasn.xyz> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] Regarding Git Tooling Date: Tue, 21 Jan 2025 12:51:44 +0100 Message-ID: <20250121125144.GB9168@haasn.xyz> (raw) In-Reply-To: <20250121024106.GF4991@pb2> On Tue, 21 Jan 2025 03:41:06 +0100 Michael Niedermayer <michael@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. > > THis was just a suggestion that seemed easier to agree with for everyone > than a hard switch vs not switch. > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > During times of universal deceit, telling the truth becomes a > revolutionary act. -- George Orwell > _______________________________________________ > 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".
next prev parent reply other threads:[~2025-01-21 11:51 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-01-20 20:39 Marth64 2025-01-20 21:09 ` Nicolas George 2025-01-20 21:12 ` Marth64 2025-01-20 22:25 ` Nicolas George 2025-01-20 22:44 ` Marth64 2025-01-20 23:28 ` Marth64 2025-01-22 12:39 ` Nicolas George 2025-01-27 20:39 ` Jan Ekström 2025-01-27 20:55 ` Timo Rothenpieler 2025-01-20 22:44 ` compn 2025-01-20 22:14 ` Leo Izen 2025-01-21 1:26 ` Michael Niedermayer 2025-01-21 1:56 ` Soft Works 2025-01-21 2:38 ` Michael Niedermayer 2025-01-21 3:22 ` Soft Works 2025-01-21 3:56 ` Kieran Kunhya via ffmpeg-devel 2025-01-21 4:03 ` Soft Works 2025-01-21 4:07 ` Marth64 2025-01-21 7:17 ` Nicolas George 2025-01-21 1:57 ` compn 2025-01-21 2:41 ` Michael Niedermayer 2025-01-21 2:56 ` James Almer 2025-01-21 3:34 ` Soft Works 2025-01-21 11:51 ` Niklas Haas [this message] 2025-01-21 17:55 ` Frank Plowman 2025-01-21 18:20 ` Niklas Haas 2025-01-21 12:04 ` Niklas Haas 2025-01-21 15:39 ` Lynne 2025-01-21 15:54 ` Michael Niedermayer 2025-01-21 16:14 ` Soft Works 2025-01-22 0:38 ` Soft Works 2025-01-22 1:08 ` Marth64 2025-01-22 2:00 ` Soft Works 2025-01-22 6:41 ` martin schitter 2025-01-25 7:54 ` Soft Works 2025-01-25 19:17 ` martin schitter 2025-01-25 22:20 ` Marth64 2025-01-21 16:22 ` James Almer 2025-01-21 17:48 ` Michael Niedermayer 2025-01-21 17:57 ` James Almer 2025-01-21 18:14 ` Niklas Haas 2025-01-25 6:57 ` Rémi Denis-Courmont 2025-01-21 16:37 ` James Almer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20250121125144.GB9168@haasn.xyz \ --to=ffmpeg@haasn.xyz \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git