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 0E94348ED0 for ; Mon, 29 Jan 2024 21:12:00 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0AE9568D265; Mon, 29 Jan 2024 23:11:58 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0243D68D22F for ; Mon, 29 Jan 2024 23:11:50 +0200 (EET) Authentication-Results: mail0.khirnov.net; dkim=pass (2048-bit key; unprotected) header.d=khirnov.net header.i=@khirnov.net header.a=rsa-sha256 header.s=mail header.b=Kz2ePQct; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id A5B5C2405F2; Mon, 29 Jan 2024 22:11:50 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavis, port 10024) with ESMTP id HMyZdZYwTJmj; Mon, 29 Jan 2024 22:11:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=khirnov.net; s=mail; t=1706562710; bh=WBTJ7bxIur59sKjLrAlNbuIOu3m11jOZAiBzka/5L1w=; h=Subject:From:To:Cc:In-Reply-To:References:Date:From; b=Kz2ePQctavqd0XF1gkdJ1P2fuj9D1/PhlXjBwTDXc2N9y50OrOwfJ1Gg23hYq42du HZyCCX0tPfr4W+To5LffMPIpa3y/dgDQbkm8gx1YbOfxFqNsP/vSt9Px3P+0wspt3w G7gm7THUCyAsSqHK+MpFrFuMBKef58V/axCwK+ZOQe+i5vz8oaEBTt7N16/1+XS0q7 u4X6qnj27p9HMLZcUbwjJg2k5fl7f/+HxRes7YS0dJE07pzVT3UQjaupBtMufgR8TY fIyWKOGrS4dPXYOdDS62oSBRc46xoXc1J5oAjMVHRxRyuPn2Ty2U/pc3ljf/Ou3HLU 7Y+pNJMCC7VZw== Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 1B2A32404E5; Mon, 29 Jan 2024 22:11:50 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id E7DA21601B9; Mon, 29 Jan 2024 22:11:49 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: <20240128032549.GN6420@pb2> References: <20240128032549.GN6420@pb2> Mail-Followup-To: FFmpeg development discussions and patches Date: Mon, 29 Jan 2024 22:11:49 +0100 Message-ID: <170656270992.8914.17597847459142276038@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 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 Cc: "Jonatas L. Nogueira" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Quoting Michael Niedermayer (2024-01-28 04:25:49) > There can be no late objections here to any project suggestions. > Objections must be before a project suggestion is submitted to STF, > objections after that cannot be considered! Self-imposed restrictions like these at the very least need a GA vote IMO. > Also once the person doing the work reaches the agreed milestone. > She will submit an invoice with stefano and my help to SPI/STF. > (in the unlikely case of a dispute on reaching a milestone > it would be decided by the technical committee if the milestone > has been reached from FFmpegs point of view) Unlikely? I believe you are overlooking and/or trivializing the most serious problems that need to be addressed before we can submit any applications and not have it end in disaster. These are, IMO: 1) How does the project protect itself from pre-approving some code that does not exist yet? This is not just some theoretical danger, it's easily possible that some project sounds good in theory, but actually implementing it comes with so many gotchas and caveats that it ends up being not worth it. Or there are fundamental technical disagreements about the specific way it's been implemented. Both cases exist in our history. 2) How do developers protect themselves from spending vast amounts of time on work they may not get paid for? As per 1), we may easily run into fundamental technical disagreements which result in the work having to be scrapped or redone entirely. It's also very hard to accurately estimate the amount of work required to do something. What do we do when someone spends a month working before realizing the project needs 5x more time than it's budgeted for? 3) Who exactly will be judging what amount of money is appropriate for what amount of work performed? How will we avoid conflicts of interest, or endless bikesheds over who is getting too much money for too little work? We just bikeshud a thread to death over rather little money, now imagine what would happen with ten times the amount. Contrary to the overall mood of this thread so far, I hope these issues can be overcome and some useful work sponsored successfully. But they need to be taken seriously first. I'd also like to ask Jonatas whether anything requires the projects to be owned by individuals. Were I to propose a project, I'd much rather it went through FFlabs than myself individually. Cheers, -- Anton Khirnov _______________________________________________ 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".