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 8303448EDF for ; Mon, 29 Jan 2024 22:43:49 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CDA3768D277; Tue, 30 Jan 2024 00:43:46 +0200 (EET) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 94BB768D243 for ; Tue, 30 Jan 2024 00:43:40 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id CF90B1C0005 for ; Mon, 29 Jan 2024 22:43:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1706568220; 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=n83zj5OywbLvG/K6Km3wAWVRBsW9f/Cl3Dqjs4OLQrE=; b=JtxAcb2C60biecOxi7TnE3AS+ihVfiRabTzcQZJe411IcMgo9VFy2Rj5dG610wlHyQ4zkE lZDDlM0qMcosvGfzNS7+5cacPdmdpB+N5kXrud3QrHg2OAMWiPew4Q1dWFGc9o5E+5QzeA si4jSSrvl6Xe0P2JcPyAXveLwTlS67g5ieq17+P998u0PaXbtL4q95hZtphRw+sOwwDrTt ZPXuLyeezr5+zozzBK7woSDh1NKZYJ3hco6h3H1Jf6QNwAfRz5LRdQvn7TCGvZ+eO79NYB i6o4Ib6Hjrlt4ySg0gS2WZxyAnxMXzW8crFtynsuGKr76SWt/SytYW09F4AuQA== Date: Mon, 29 Jan 2024 23:43:39 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240129224339.GG6420@pb2> References: <20240128032549.GN6420@pb2> <3527245.gu6uECoyUc@basile.remlab.net> <20240129181119.GZ6420@pb2> <2011399.K0GceMP4zf@basile.remlab.net> MIME-Version: 1.0 In-Reply-To: <2011399.K0GceMP4zf@basile.remlab.net> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] Sovereign Tech Fund 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="===============1365992993222664092==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1365992993222664092== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7H0jZ9qvFb5Bk2W+" Content-Disposition: inline --7H0jZ9qvFb5Bk2W+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Mon, Jan 29, 2024 at 11:01:05PM +0200, R=C3=A9mi Denis-Courmont wrote: > Le maanantaina 29. tammikuuta 2024, 20.11.19 EET Michael Niedermayer a = =C3=A9crit : [...] > > Its under the control of the community and its transparent >=20 > You always have the control of the community at the time of review and me= rge. >=20 > You can argue all you want that more open is better. What I see is that t= his=20 > more open is already turning into a train wreck (as predicted last year). I do have to disagree on this specific point The people predicting it to be a train wreck are the people who now make it a train wreck. >=20 > > And very important what do you propose ? >=20 > We already went through this in the previous thread last year. This is no= t=20 > going to work in the light of what Jonatas politely calls FFmpeg "governa= nce"=20 > challenges. It was already clear that finding agreement within the GA wou= ld be=20 > at best very difficult and untimely. >=20 > People (including myself) already suggested to arrange that sort of thing= s via=20 > an IT service company (*not* necessarily FFlabs). Or you could even go th= rough=20 > a "porting" company in your country if you can't find an existing agreeab= le=20 > company and don't want to register your own. Of course those are not perf= ect=20 > solutions but they seem far less fraught with problems than going through= a=20 > foundation, especially a US-based foundation. You can review the archives= for=20 > details. Of course we can discuss this and vote on it. Personally i believe SPI is a= good choice. And especially a safe choice. And it will be difficult to find a choice that doesnt have some agenda and does this for free. SPI has served many open source projects over a long time. Adding an entity that handles FFmpegs finanaces needs to be done carefully It should not be a newly formed entity and it should not be an entity related to multimedia. So for example a >10 year old entity that is truted by many diverse open so= urce projects. (like SPI) But either way that would not be a quick process finding an entity that everyone trusts wou=C4=BAd not be easy. So i still s= uggest we go with SPI even for future STF rounds [...] > > > That drama > > > couldn't be had for GSoC because how was however Google decides, and = there > > > was no intermediary to go through (money went straight from Google to= the > > > students). > >=20 > > SPI handles all the GSoC mentor money. > > And lets just assume it would handle the students money too, what diffe= rence > > would that really make ? >=20 > It would cause similar arguments to this one. And that's if Google would = even=20 > agree to such a setup (which I guess they wouldn't). >=20 > What is the point of going through SPI for *this* (as opposed to regular > donations)? iam not 100% sure i understand your question. Our donations are handled by SPI and STF will not pay developers directly, this is not an option. This was asked= early thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt compla= in" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" --7H0jZ9qvFb5Bk2W+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZbgqFwAKCRBhHseHBAsP q2DvAJwLFzo1X06GD0gqzJperV9+/6uUKwCgmlkv27U63vZSABD5o4gDNyzjw1M= =WVNc -----END PGP SIGNATURE----- --7H0jZ9qvFb5Bk2W+-- --===============1365992993222664092== 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". --===============1365992993222664092==--