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 B1DE849179 for ; Sun, 4 Feb 2024 19:28:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ED7FF68D0B4; Sun, 4 Feb 2024 21:28:51 +0200 (EET) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B3F0F68D0B4 for ; Sun, 4 Feb 2024 21:28:45 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id E8D5A240002 for ; Sun, 4 Feb 2024 19:28:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1707074925; 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=7Ca93G0Q23kGO0fWLPQvHNZGmuPRU7NGlJxZnpRnNMo=; b=PPtHA513DA6tSh4zKZJfYJ09bcq4ObAL68IBv178WWGaWFhP4p+E8N/WliaShq6VMI76+w U32H49ePzEuRC3K/jJkR5t7iIcGHQe1slukoo6AtMEGJmBJ8ST+hXvCVezKJCVm8Tcs4J6 H3RTHZhR0Tr+X0iq+Ue508LB79V5UHfonK0hGVzn6xXqRr8jpAroiB5Evbs0EIOskqQZUx IghyaD6mXbUviSouAXzAfcYRGqNRQHCL2DTmRa+KWwgXJ8ApkiImVrLiq+BGSrRfdqXNQF c2/z+gqNkFBA/s/f3q8JtSuhQC1zedGhYd4e4TA27vzlVVT1Q5eBAqLReXSOcg== Date: Sun, 4 Feb 2024 20:28:44 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240204192844.GP6420@pb2> References: <20240128032549.GN6420@pb2> <20240130014821.GJ6420@pb2> <36880d31-320c-419f-ae4d-42a5eade0ebe@gmail.com> <79E1CAE3-5019-403D-839C-93C569B00BED@remlab.net> <0948568f-bd7e-47e7-bb92-39e19def951d@app.fastmail.com> <20240204134115.GO6420@pb2> MIME-Version: 1.0 In-Reply-To: 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="===============0802624644129954087==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0802624644129954087== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wdo7VbI22JyqaZpV" Content-Disposition: inline --wdo7VbI22JyqaZpV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 04, 2024 at 03:38:43PM +0100, R=C3=A9mi Denis-Courmont wrote: > Hi, >=20 > Le 4 f=C3=A9vrier 2024 14:41:15 GMT+01:00, Michael Niedermayer a =C3=A9crit=C2=A0: > >Hi > > > >As said on IRC, i thought people knew it, but =E2=80=98the same person a= s before=E2=80=99 is Thilo. > > > >Ive updated the price design suggestion for the merge task, its 16=E2=82= =AC / commit limited to 50k=E2=82=AC > >this comes from looking at pauls fork which has around 500 commits in 2 = months thus > >250 commits per month, 12 months, and if we allocate 50k that end with r= oughly 16=E2=82=AC / commit > >if activity stays equal. >=20 > It's very different if we're talking about librempeg or some other unspec= ified fork. I could make a fork that removes MMX et al, and claim that I'm = merging a fork. There are so many reasons why this wouldnt work (first you would have to lie, i dont think you would, then it would not be left that way on the wiki, not being sent to STF that way and not being accepted by STF and more) But assuming one could get away with that in the short term Why would anyone do something like this to destroy our all opertunity to obtains grants in the future ? >=20 > >The task has ATM no developer on it. If a developer adds himself, he can= change teh task > >and specify what he proposes to merge. > > > >I am totally perplexed why every dot on every i is such a big thing. >=20 > That is the whole point of a statement of work. And I agree that it's ted= ious and possibly outright annoying... >=20 > Indeed I don't think that a semiformal open-source community with a lot o= f strong and varied opinions will carry such dotting of all i's very effect= ively. That has been one of the arguments for delegating this to a contract= ing IT company rather than to FFmpeg-devel and SPI. If the FFmpeg team can make decissions about what to fund then we do not ne= ed any contracting IT company. OTOH If the FFmpeg team is not able to make decissions, thats a far bigger problem and it needs to be understood and corrected But not only this "delegating this to a contracting IT company" really means having a random CEO make the decissions about FFmpeg instead of the GA or community. It is unlikely this will be accepted by the GA. And if accepted it would be the end of FFmpeg. We would have not even sold FFmpeg we would have given it for free to some company. Because whoever controlls the income of develo= pers effectively controlls the project. An emloyee has to do what she is being told be her employer. So if the main= developers become employees payed to work on FFmpeg that would hand FFmpeg to some CEO= on a silver plate, This would change FFmpeg from a Free software project to a commercial compa= ny. I do NOT agree to this, and i belive many others also do not agree. I am happy if we can get people payed continuously from grants and other so= urces but never should FFmpeg give up its autonomy Also we have "a lot of strong and varied opinions" but IMHO that is not the= problem here. The problem is distrust. Using an "contracting IT company" will make this worse, First we will not agree on it and if we do, we will end with a fork, whoever is n= ot "friends" with the CEO of that company will leave. SPI or a similar entity gives us the transparency where a group of people who distrust each other can move forward without the need to trust a 3rd pa= rty Everyone can add their entry to the wiki, everyone has the same rights to edit it. Everyone elected the TC. I dont think a failure of SPI-STF will result in the money going next time = to a contracting IT company. We have the opertunity to move forward together here. Or we can choose not to move forward Or we can choose not to do it together Thats fundamentally the choices. In a mathematical sense, there are no othe= r choices I favor moving forward together! thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein --wdo7VbI22JyqaZpV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZb/lZQAKCRBhHseHBAsP q0kRAJ9k6Y1UnN4wt6NsQYPhj4ikSSjSwACgmwYRjeHVLp+A/O9mUEIn3whND8g= =rnxS -----END PGP SIGNATURE----- --wdo7VbI22JyqaZpV-- --===============0802624644129954087== 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". --===============0802624644129954087==--