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 ESMTP id 7EA9647811 for ; Wed, 21 Feb 2024 12:50:50 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 396BA68CF70; Wed, 21 Feb 2024 14:50:48 +0200 (EET) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 347AD68CC25 for ; Wed, 21 Feb 2024 14:50:42 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 48350C0005 for ; Wed, 21 Feb 2024 12:50:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1708519841; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J4QFbfBNGCCdKCejE4ZPqGC3uU0720twxd+1MBHNaXw=; b=AqiGPzjdMla0GoP977gO+Ty1Qese8hWe3OkAn3w1itC7TMSeNBz9No35DLiveyYiJR8465 nJtGeow+A7Umc+J+SuwaOvW1KZ4ufpSZYNuKXCMFNOOIzBfA6FFq/LC1CmXksfaHXG/Hr0 Br2S5x481GMD0R54M8Ui6rjyK059FA1oRL1mosxFMbD4k1jr81CFDhnMBuzGmBZooi2rjb dnWuN9Kr3tmU+Gs0+ancPG06TRn1sk0ca0RS+Z+ccz5IUf0fP+MZyNuS/Gsn7L87qTaPiT FAqbgUOBTiUop7QNb8R5FtDftwV/rk/ZU1lsXb0IFT5KbqFZ+SkOjmDzk+xTaQ== Date: Wed, 21 Feb 2024 13:50:40 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240221125040.GZ6420@pb2> References: <20240220143134.GT6420@pb2> <0fe648d5-d5b1-4cf3-a88f-0a5cf121e653@betaapp.fastmail.com> MIME-Version: 1.0 In-Reply-To: <0fe648d5-d5b1-4cf3-a88f-0a5cf121e653@betaapp.fastmail.com> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [RFC] fate rsync switch to git 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: multipart/mixed; boundary="===============1468685186476602158==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1468685186476602158== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="epHEM7uSroVC8fX8" Content-Disposition: inline --epHEM7uSroVC8fX8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2024 at 02:39:42AM +0100, Jean-Baptiste Kempf wrote: > Yo, >=20 > 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 ? >=20 > Yes, that's my idea. >=20 > The git part is not for others clients to sync, but just to manage the sa= mples. >=20 > It allows to have versioning of the samples, with the extra ability to ha= ve 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", becau= se their would be multiple approvers/committers to that repo. we have 15 people in the samples group that have the power to upload sample= s, 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 mirro= rs. 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 s= ample 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 te= st 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 [...] --=20 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. --epHEM7uSroVC8fX8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZdXxnAAKCRBhHseHBAsP q4BBAJ9GYBgHeZRYZxPq5PJPKLzqUhJ/WwCfRlQaQxL7wV8QZQu84kTdHgbIdNE= =lWIQ -----END PGP SIGNATURE----- --epHEM7uSroVC8fX8-- --===============1468685186476602158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============1468685186476602158==--