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 589F04927B for ; Tue, 6 Feb 2024 18:17:27 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id EBA1768D065; Tue, 6 Feb 2024 20:17:23 +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 F2C1568CB2D for ; Tue, 6 Feb 2024 20:17:16 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 25B8E240005 for ; Tue, 6 Feb 2024 18:17:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1707243436; 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=0aPtQSrsvilk0q1NSEl9ko+4yT66l/NPWY0LgqhnGz4=; b=ocn03gKnWiLQc3FV9F2016L/a7aUftceP6r3hdPUaIQeUvhqUwk5gLqqhZIvFrcQhXGTBZ p3UtZxuYKWtSPOz4SuMNp03WfCReHK2w7P2ZTkqomn2gBTZEO5Dd47wpVLsOouAgsXx5ty hpitSXhHj/hMAQ7eaAwreOVYL1xnJtJ1E3dM7yUOgHkCcykDCJqqmvYZMybTe+0/xp1UGu mu013r8hTeM+fUYf8C7rfJ3mkUoCjJPBj32jLWPR0nb6Xdml4Kpe6sh5F/QsBwuA6RgF/J mDG/B+EbAJiIxL24qIrp9Hv2JTK/qA8GPyRfeKLqH84DN0Hy/FETjwUTVl6skA== Date: Tue, 6 Feb 2024 19:17:15 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240206181715.GB6420@pb2> References: <20240206020642.GW6420@pb2> <20240206151457.GX6420@pb2> <20240206170443.GE61936@haasn.xyz> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] STF SoWs 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="===============3911880414543870796==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============3911880414543870796== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dLs6WvV9UwaVp38n" Content-Disposition: inline --dLs6WvV9UwaVp38n Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Tue, Feb 06, 2024 at 12:02:51PM -0500, Ronald S. Bultje wrote: > Hi, >=20 > On Tue, Feb 6, 2024 at 11:05=E2=80=AFAM Niklas Haas wr= ote: >=20 > > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" > > wrote: > > > Hi, > > > > > > On Tue, Feb 6, 2024 at 10:15=E2=80=AFAM Michael Niedermayer < > > michael@niedermayer.cc> > > > wrote: > > > > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > > > Hi, > > > > > > > > > > On Mon, Feb 5, 2024 at 9:06=E2=80=AFPM Michael Niedermayer < > > > > michael@niedermayer.cc> > > > > > wrote: > > > > > > > > > > > 2. Deliverables > > > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > > > > > Yes but the individual developer cannot gurantee that. > > > > > > > > > > In a bad situation, someone could send unmergeable patches and they w= ill > > > satisfy the legal requirement above for being paid out. I'm suggestin= g to > > > protect the project against that situation. > > > > Unless I misunderstood you, what you are proposing protects the > > Sovereign Tech Fund (aka German government), not the FFmpeg project. > > This would only be a concern if we were funding work directly from the > > (non-existant) FFmpeg treasury. > > >=20 > It was more about project reputation and the goals being pro-project rath= er > than pro-developer. Look at it this way: if patches get submitted but not > merged, is FFmpeg helped? Probably not. But money was spent using FFmpeg's > reputation to secure the funding. Subsequent funding rounds will be more > difficult. > Requiring a merge protects the project against this bad > situation. "Requiring a merge" does not do that because lets assume we have a SoW that says "merge to git master" is needed now this merge is blocked by someone successfully That means the SoW is not fullfilled, the developer is not payed and STF has paid SPI. That would ruin FFmpegs reputation even more as STF is unhappy (they paid and didnt get what was written in the SoW) the developer was not paid, so she would definitly be unhappy SPI as the one in the middle would also be in a very uncomfortable position. So i think we should make sure the conditions in the SoW are guranteed to be achievable >=20 > I understand that, hypothetically, if STF had funded SDR, this would be > problematic, because no payment is possible for work a majority of the > project's constituents doesn't want in. But maybe that ensures project > funding is requested for conservative sets of tasks that everyone agrees > are good for FFmpeg. So I don't see it as all bad. I don't think anyone is > realistically planning to find a GA or TC majority to block patches that > fix problems found by a static analyzer from going in, purely because it = is > known that work was paid for? That doesn't sound realistic to me. We've > historically approved such patches without knowing it being declared > whether they were paid for or not. We have had multiple fixes blocked from going in. There was the "i have a file this breaks, i will not share the file" cases There where timeout fixes blocked because someone did not like some check There was even general argumentation about OOM/Timeout fixes to be better not done and rather running ffmpeg in a VM (which does not solve the problem that the timeouts slow the fuzzer down) Some fixes involving checking file extensions and similar also where not popular There was a time some people tried to block bugfixes if they printed an err= or message. (thats why now none of my fixes prints an error message unless sim= ilar cases do already) I even remember that a paid bugfix in a demuxer (mov?) was rejected, the cu= stomer was perfectly ok with that and paid me. I think i pointed it out to him prior like i do with everyone nowadays that merge to git master cannot be guranteed. This is just what i remember at the spot. Assuming the TC will solve it is brave because the TC is new and predates most of the examples above. I disencourage people from putting "merge into git master" as a deliverable. It can get you burned in FFmpeg. > > But look at it from a higher level: you guys are asking for review of the > STF task proposals, and I'm trying to find problems where they exist. I > don't think the problem I find - or solution I propose (s/submit/merge/) - > is crazy. I'm OK with different "fixes" for this problem I'm pointing out. > But saying that it's not a problem... I disagree with that. if "merge to git master" is a requirement then iam not participating in this. The risk simply outweights the gain. I wont work for months to then be at the mercy of not a single of 2000 subscribers posting some "i object" and all 2000 know in this situation it would cause an inconvenience to me. I also recommand everyone else not to put their signature under a SoW that lists things they cannot gurantee to achieve. I have once lost a l= arge customer from not considering adequately the FFmpeg communities ability to = block things. So its not even a hypothetical problem (no, noone knew it was paid = work it was not intentional) 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" --dLs6WvV9UwaVp38n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZcJ3qAAKCRBhHseHBAsP q5KmAJ4qkPnQcZ4HYp+PG6srXcqdiuZR8gCfQWizV26jN4VZdWzqhdhlbGaiTkQ= =yvom -----END PGP SIGNATURE----- --dLs6WvV9UwaVp38n-- --===============3911880414543870796== 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". --===============3911880414543870796==--