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 70E244AF44 for ; Fri, 24 May 2024 10:50:57 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 15E6568D536; Fri, 24 May 2024 13:50:55 +0300 (EEST) Received: from shout02.mail.de (shout02.mail.de [62.201.172.25]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CB00C68D4C1 for ; Fri, 24 May 2024 13:50:48 +0300 (EEST) Received: from postfix02.mail.de (postfix02.bt.mail.de [10.0.121.126]) by shout02.mail.de (Postfix) with ESMTP id 676222420F1 for ; Fri, 24 May 2024 12:50:48 +0200 (CEST) Received: from smtp01.mail.de (smtp04.bt.mail.de [10.0.121.214]) by postfix02.mail.de (Postfix) with ESMTP id 4DCC4A00E2 for ; Fri, 24 May 2024 12:50:48 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp01.mail.de (Postfix) with ESMTPSA id 033EE24184D for ; Fri, 24 May 2024 12:50:47 +0200 (CEST) Message-ID: <2b767473-d6f5-4ce2-a15f-ec9443b11741@mail.de> Date: Fri, 24 May 2024 12:50:47 +0200 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org References: <20240517134958.GQ6420@pb2> Content-Language: en-US In-Reply-To: X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-purgate-size: 2474 X-purgate-ID: 154282::1716547848-787CD338-C214B760/2/58476994140 Subject: Re: [FFmpeg-devel] [RFC] STF 2025 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: , From: Thilo Borgmann via ffmpeg-devel Reply-To: FFmpeg development discussions and patches Cc: Thilo Borgmann Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 24.05.24 11:56, Andrew Sayers wrote: > On Fri, May 17, 2024 at 03:49:58PM +0200, Michael Niedermayer wrote: >> Hi all >> >> Before this is forgotten again, better start some dicsussion too early than too late > > This comment is inspired by the other subthread, but not directly in reply to it. > I'm replying to this post rather than get in the middle of all that... Thanks :) > What happens if someone is hired to do a job that requires access to the ML, > then gets involved in a situation where there's talk of a ban? > > If they're banned, does that translate to suspension without pay? With pay? > > Banning such a person would jeopardise future funding - if they aren't banned, > will people be concerned about the apparent conflict of interest? Interesting and something we should think about. I think the project's well-being should be the priority - meaning if we vote for a ban of someone that was trusted enough to get a contact from us in the first place, the ban should be executed - or any other measure the CC or GA sees fit. Giving a work contact to someone shall not make us dependent on that person to such an extent. > In a wider sense, hiring a single person to do a job we come to rely on (like > code review) gives the project a bus number of 1. How would the STF react to > a proposal like "we plan to do XYZ in 2025, but if we don't get funding for > 2026, we'll drop Z and spend the time on a transition plan instead"? Speaking as an idealist, we should uphold our procedures independently of what another entity (except the applicable law) thinks about our decisions. Realisticly speaking, we already got some feedback from STF about such potential break aways on our end. Though these are of course never good in any such business relation, these things do happen. So up to a certain extend, it won't remove us from the program. Problems arise if such things are getting frequent. We also got another layer of protection vie the SPI linked in between. If we sanction someone severely who is in current posession of a contract to do some FFmpeg work, we might stop funding that and give another contract to someone who can take over. Not saying that this could work with any kind of work but can be an option. That brings me to the idea that we need to check the contracts for potential fail-safe clauses for such extreme cases like these. Thanks, Thnilo _______________________________________________ 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".