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 70E8749066 for ; Wed, 31 Jan 2024 21:26:56 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9131D68D0B0; Wed, 31 Jan 2024 23:26:54 +0200 (EET) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 20CA768BED3 for ; Wed, 31 Jan 2024 23:26:48 +0200 (EET) Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-5112cb7ae27so338063e87.0 for ; Wed, 31 Jan 2024 13:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706736407; x=1707341207; darn=ffmpeg.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=UM/MOt2Z4SVhnbOGnLfJGlW81ntxvG5Awdvdq3T6XX0=; b=Q5mRu0AME7EJz1s86KPak6AWzAQteuopz3pOJg4ELDnK8WUpQXHcNKvy54NX3e3brx UDSOTePMpIRv+VeOVkotxcs7FchaCuwKzh8UEV39K2qqwA1c/zAqHYRHut/XhGM+rF6T pLd51gb/Z2x34h0F3/bXM4fmAX4awIuD0nBWNTuJ6Rp4LE5+LlzTNRc4nMXGvntuGbfg mZUB5cvbYugwkXYh1051GWDtR+8S05LxQT4o6Fx81B5GizQcK2+S9DZo1+zmoz2z3AFW 8pMwTJcZvME//TzxBOC0NXBdbE/hK3a22CNNV4wAglU+/xrGyRyXNXObgssjD2+Vnz0B XO3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706736407; x=1707341207; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UM/MOt2Z4SVhnbOGnLfJGlW81ntxvG5Awdvdq3T6XX0=; b=TjM7ACPI3Dr6APzFUu5JOQ0Ol84zYkpa53TXCWVU9Jrk0VT1LIw93MaN6FmTrgNu0X CGG3Wnv7E2I2wtug6GyJ7aZnOxxFFbF/90ImC2t9FJInPmY+v5HVw4hi9p+/1x+Jw7K+ p+LnaRU7hwo2MOsMfVwVXUa2mRfUL6Ufmszgkjj62KtXLvvc7OaT1z1v+rbhZplJfI/A WBQtL7HaNyUSi6MbiLXmOyNJ+UfX2P0CytDOGrkfn+2/F4L5UuWg5enKx465NbMngSJA Sl2bQ797BkswPLaWdTQ1LB+p7+MdWHaYt71OfMMpjHrMn0xpEfhktCysP7tGqmIhE2Kj Dyiw== X-Gm-Message-State: AOJu0YxP2eu5tl/1E73b5lArc6i+1LDbS7DPe37Ca9jYhGqi5bzGDIG1 ePUkOIwljnB0ZkMVCAhOzNCNwQZaZieapIE1St62zCe/Mz+6qXypGOJfqBtl X-Google-Smtp-Source: AGHT+IFY+gznst8kcbc+339+Y62o9FKT6Vcj0hNfodc2qNN84ZgUWN9L3jd2QvA4nVgmpO6jnxyIdw== X-Received: by 2002:ac2:5f50:0:b0:50e:ac97:8bbe with SMTP id 16-20020ac25f50000000b0050eac978bbemr485334lfz.45.1706736406665; Wed, 31 Jan 2024 13:26:46 -0800 (PST) Received: from mariano (dynamic-adsl-84-220-189-10.clienti.tiscali.it. [84.220.189.10]) by smtp.gmail.com with ESMTPSA id tk3-20020a170907c28300b00a35464aab3asm5365887ejc.97.2024.01.31.13.26.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Jan 2024 13:26:46 -0800 (PST) Received: by mariano (Postfix, from userid 1000) id 357B1BFB9D; Wed, 31 Jan 2024 22:26:45 +0100 (CET) Date: Wed, 31 Jan 2024 22:26:45 +0100 From: Stefano Sabatini To: FFmpeg development discussions and patches Message-ID: Mail-Followup-To: FFmpeg development discussions and patches References: <20240128032549.GN6420@pb2> <170656270992.8914.17597847459142276038@lain.khirnov.net> <170670425036.8914.15189015352946522304@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <170670425036.8914.15189015352946522304@lain.khirnov.net> User-Agent: Mutt/2.1.4 (2021-12-11) 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On date Wednesday 2024-01-31 13:30:50 +0100, Anton Khirnov wrote: > Quoting Stefano Sabatini (2024-01-30 00:53:25) > > On date Monday 2024-01-29 22:11:49 +0100, Anton Khirnov wrote: [...] > > > 1) How does the project protect itself from pre-approving some code t= hat > > > does not exist yet? This is not just some theoretical danger, it's > > > easily possible that some project sounds good in theory, but actua= lly > > > 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. > > = > > The design and investigative work should be covered as part of the > > SOW. In other words, the SOW should also cover the preliminary design > > and experimentation. In case it leads to no committable work (which is > > unlikely but not impossible), the output should be a document/report > > documenting the result of the initial investigation, and the project > > might be aborted at that point. > > = > > This should protect both the developer and the project. In each case > > it should be assumed that the final result of the investigation would > > not lead to committable deliverables, but to design documents which > > might lay the foundation of further work (possibly in a different > > direction). > = > That might be a viable direction, but it does not really solve the > problem. Initial investigation only gets you so far and some issues > simply do not become apparent until quite far in the development > process. > = > E.g. my recent threading work (that keeps getting mentioned in this > thread as an example of what a cleanup project could look like) was > largely composed of many "sub-projects", each disentangling a specific > feature or area. And there was no reliable way to predict in advance > whether a given sub-project would take two hours or two weeks. So let's tweak the format. It might be formulated as something as: --------------8<---------------------------------------------------- This project covers doing this and that. It will be split in several stages lasting a given amount of time (e.g. two months per each stage). At the end of each stage the developer will provide a report giving an overview of the findings and of delivered code, which will be the subject of the invoice. --------------8<---------------------------------------------------- In this way we drop the requirement on achieving a specific goal in terms of committed code, and require instead a report to document the changes/finding (which will be subject to validation). Maybe Jos=E9 can provide some guidance about the viability of this specific format. Assuming this format is acceptable on the STF/SPI side, the next problem is to understand who is going to provide the validation based on the report. The SPI liaison might be involved but only to sign-off, not to provide the actual validation, which must be agreed upon by the project according to some agreed internal procedures. Other issues might arise in case the work is delayed due to various circumstances (e.g. the developer getting sick or having other external impediments or having more urgent tasks to attend). In this case I can foresee a few possible outcomes: the developer will delay sending the invoice, or the invoiced sum is reduced accordingly. It seems to me we need to design these validation processes in advance or we risk to turn each invoice delivery into a potential flamefest. _______________________________________________ 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".