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 354BC492ED for ; Wed, 7 Feb 2024 12:58:30 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1D6F268D188; Wed, 7 Feb 2024 14:58:28 +0200 (EET) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 47C5068BC30 for ; Wed, 7 Feb 2024 14:58:22 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 729E660002 for ; Wed, 7 Feb 2024 12:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1707310701; 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=aLTjMOvLvKbLDpyy3QY2224VWdp83Zxw5+EJ8sVgi+Q=; b=eANOxyNI4erypoV/wLSWvCbEFAPV54CW/iDHxC38uonGOyb5cuHWQJRx3Q/l8Q2WcCemb1 /IQ272LSdfC+wCL9QpjlyLsR1tOeaCbColbX8ExUiHWDJTq+Lmq0jHyAdlxgPaQTYuUXNT hTxGZRi6ef6fJc6Olz/YRFQJqbePpxtDcJqVh6R6cmZrtWQ8022tHy2jlkTCeKtftjJHSC w06NZVl7SPDvONvnURDW87xtXs+EP4gYph6nT7jNGEoRhFoyy9o3Fq2d/5rGuUMaF74fJy lYHa2Z1GIA2anFWVJFgZyHuAHEKW7CJgqtab0h1IViLk2GZyJdcjQtChltuVTA== Date: Wed, 7 Feb 2024 13:58:20 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240207125820.GF6420@pb2> References: <20240206151457.GX6420@pb2> <20240206170443.GE61936@haasn.xyz> <20240206181715.GB6420@pb2> <20240206212304.GD6420@pb2> <20240206230449.GE6420@pb2> 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="===============5951716113253434736==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============5951716113253434736== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fg5E0qDZkga2e+qk" Content-Disposition: inline --fg5E0qDZkga2e+qk Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 06, 2024 at 08:38:13PM -0500, Ronald S. Bultje wrote: > Hi, >=20 > On Tue, Feb 6, 2024 at 6:04=E2=80=AFPM Michael Niedermayer > wrote: >=20 > > I think you should sign a SoW that has "Merged in git master" as a > > Deliverable > > >=20 > I already did. It was fine. of course its fine 9 out of 10 times but 1 out of 10 times the customer is unhappy and you are unhappy. I like being transparent and explain this possibility to the customer/buisn= ess partner. because no matter whats written in a contract, sometimes some patches cannot be merged in git master. >=20 >=20 > > PS: do you have a single person willing to sign this Deliverable you > > want ? > > If not, how will the STF thing work ? > > >=20 > You're asking for community input for your proposal, I gave comments as > requested. It's OK to disagree on things, happens all the time. yes, but i was hoping we could find something we both agree on > You can A) > ignore my suggestions and submit the proposal to STF anyway, > B) submit a > proposal to STF as yourself rather than as FFmpeg (but for the same tasks, > on FFmpeg), > C) submit a proposal using another company/non-profit (e.g. > fflabs), > D) not submit a proposal to STF, > or E) something else ??? Its more complex Theres the person writing a SoW for work he wants to do. Theres the person who accepts the SoW in FFmpeg Theres the person who passes accepted SoW on to SPI/STF Iam sadly involved in more than one role here. If everyone including you agree on whats written in the SoW, i think its ok but if you disagree I cannot override or bypass that. That said, we from the point of view of FFmpeg should not promise STF that we can merge code in git master before its written. It could fail and would make the project look bad STF is about maintainance, analyzing bugs, fixing bugs, submitting patches reviewing patches maybe. Promising them that the whole community will accept every change. Which is what "merge to git master" is. Is not needed In fact it might even be counter productive. STF probabyl does not want thi= ngs to be merged that people do not agree on. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives.= =20 -- Abba Eban --fg5E0qDZkga2e+qk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZcN+aAAKCRBhHseHBAsP q+YxAJ425uS272IsI14hskmKVk93z/ForgCgls+bd/oOckNCIZixZbnCQyPikoA= =r2Nt -----END PGP SIGNATURE----- --fg5E0qDZkga2e+qk-- --===============5951716113253434736== 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". --===============5951716113253434736==--