Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

      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