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 ESMTPS id 6574A48F69 for ; Mon, 20 Jan 2025 21:04:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8832468B672; Mon, 20 Jan 2025 23:04:32 +0200 (EET) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4937868B234 for ; Mon, 20 Jan 2025 23:04:26 +0200 (EET) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 50KL4P83011128 for ; Mon, 20 Jan 2025 22:04:25 +0100 Received: by phare.normalesup.org (Postfix, from userid 1001) id 8EA512EFE0; Mon, 20 Jan 2025 22:04:25 +0100 (CET) Date: Mon, 20 Jan 2025 22:04:25 +0100 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20250102141731.GR4991@pb2> <4f72a0e8-d5f2-4796-8376-aa5790f2bd97@gyani.pro> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4f72a0e8-d5f2-4796-8376-aa5790f2bd97@gyani.pro> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Mon, 20 Jan 2025 22:04:25 +0100 (CET) Subject: Re: [FFmpeg-devel] Democratization 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="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Gyan Doshi (12025-01-20): > This the crux of the matter. There appear to be two camps at odds with one > another: > > 1) a conservative camp which wants to avoid features or changes which don't > neatly fit within a conventional pure architecture with clear separation of > roles and duties, or features which are of use only to some users > > and, > > 2) a broadband camp which accepts features which are niche or which require > some hybrid accommodation in its implementation. This is a good point, and I agree with your analysis. > For most of ffmpeg history, the latter has been the dominant camp. But not > in recent history. Let us add that the camp that wants more stability than originality already tried to become the dominant camp in the last years of the 2000s decade, with the same strategy of bullying Michael. They eventually had to split into their own project, but it died. > Tweaking the structures or procedures of governance can't ultimately bridge > this chasm. It's almost like these camps should be part of different > projects. I agree with that too. Or at least different and separate branches of the same project. But an important point: the stable-without-originality branch needs to be downstream of the creative branch. It is the same as Debian: you do not make Debian unstable by adding features to Debian stable, you make Debian stable by freezing and polishing Debian unstable. The libav fork failed in part because it tried to be the upstream (and pretend it was alone). I would say it amounts to about half the reason it failed, the other half being the personality of its de-facto leaders. Regards, -- Nicolas George _______________________________________________ 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".