From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [RFC] fate rsync switch to git Date: Wed, 21 Feb 2024 13:50:40 +0100 Message-ID: <20240221125040.GZ6420@pb2> (raw) In-Reply-To: <0fe648d5-d5b1-4cf3-a88f-0a5cf121e653@betaapp.fastmail.com> [-- Attachment #1.1: Type: text/plain, Size: 2753 bytes --] On Wed, Feb 21, 2024 at 02:39:42AM +0100, Jean-Baptiste Kempf wrote: > Yo, > > On Tue, 20 Feb 2024, at 15:31, Michael Niedermayer wrote: > > I did hear (at fosdem?) > > about the idea to switch from rsync to git for managing the fate samples > > i thought the idea sounds interresting but isnt rsync more efficient ? > > Yes, that's my idea. > > The git part is not for others clients to sync, but just to manage the samples. > > It allows to have versioning of the samples, with the extra ability to have branches and tags matching the ffmpeg branches. versioning is fine branches, we did not need, and adding branches sounds like a solution searching for a problem > It avoids the weird dance "waiting for FATE admin to upload thing", because their would be multiple approvers/committers to that repo. we have 15 people in the samples group that have the power to upload samples, the bottleneck is that only 2 of them actual do upload and noone else is volunteering > It simplifies the workflow on the admin side, since with a git hook, the server does "git update" in the directory that will be rsync'd by the mirrors. And it does not change their workflow, still using rsync. It still requires people to push the new sample to git and that git is a different architecture than how the samples normally where downloaded if you keep rsync I mean everyone has a rsync based checkout like now for "make fate" updating with "make fate-rsync" they add a sample to this and then they have no git to push that to cuz, no .git directory is there. This can be handled in a few ways but it mainly seems messy what i suggest is that someone adds a make fate-rsync-upload that runs the rsync command that way the other people who actually have fate samlpe upload rights actually do the upload after testing a patch instead of waiting for 2 people to do it. Such "fate-rsync-upload" is easy and needs no change to architecture it also doesnt make any future change to architecture any more difficult so i suggets that to be done together with people volunteering to do fate sample uploads themselfs if they freuqently review/approve patches that need such uploads If people prefer switching to git then we need an volunteer to write and test the related hook(s). I can create a git repo for it Iam mainly hesitant now because it seems an additional layer not replacing a layer thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] [-- Attachment #2: Type: text/plain, Size: 251 bytes --] _______________________________________________ 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".
prev parent reply other threads:[~2024-02-21 12:50 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-20 14:31 Michael Niedermayer 2024-02-20 18:43 ` Jan Ekström 2024-02-21 14:38 ` Niklas Haas 2024-02-21 14:50 ` epirat07 2024-02-27 18:57 ` Vittorio Giovara 2024-02-21 1:39 ` Jean-Baptiste Kempf 2024-02-21 3:13 ` Zhao Zhili 2024-02-21 12:50 ` Michael Niedermayer [this message]
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=20240221125040.GZ6420@pb2 \ --to=michael@niedermayer.cc \ --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