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 9084E4B977 for ; Tue, 2 Jul 2024 09:56:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B09C468CE20; Tue, 2 Jul 2024 12:56:48 +0300 (EEST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id F205B68D245 for ; Tue, 2 Jul 2024 12:56:41 +0300 (EEST) Received: from a.0.4.0.3.4.0.7.b.f.1.8.d.d.c.c.0.5.8.0.9.1.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:819:850:ccdd:81fb:7043:40a] helo=andrews-2024-laptop.sayers) by painless-b.tch.aa.net.uk with smtp (Exim 4.96) (envelope-from ) id 1sOaFd-00DDrj-0o for ffmpeg-devel@ffmpeg.org; Tue, 02 Jul 2024 10:56:41 +0100 Date: Tue, 2 Jul 2024 10:56:34 +0100 From: Andrew Sayers To: FFmpeg development discussions and patches Message-ID: References: <20240418150614.3952107-1-ffmpeg-devel@pileofstuff.org> <20240604144919.213799-1-ffmpeg-devel@pileofstuff.org> <20240604144919.213799-2-ffmpeg-devel@pileofstuff.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Subject: Re: [FFmpeg-devel] Development process for explaining contexts (was Re: [PATCH v6 1/4] doc: Explain what "context" means) 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: On Tue, Jul 02, 2024 at 12:16:21AM +0200, Stefano Sabatini wrote: > On date Sunday 2024-06-16 19:02:51 +0100, Andrew Sayers wrote: [...] > > Andrew, sorry again for the slow reply. Thinking about the whole > discussion, I reckon I probably gave some bad advice, and I totally > understand how this is feeling dragging and burning out, and I'm sorry > for that. > > I'm still on the idea of erring on the side of under-communicating for > the reference documentation (with the idea that too much information > is just too much, and would scare people away and make it harder to > maintain the documentation, as now you have to check in many places > when changing/updating it, resulting in contradicting content). > > So at the moment I'd be willing to publish an abridged version of your > latest patch, with the suggested cuts - I can make the edit myself if > you prefer like that. This way we can get the non controversial parts > committed, and we can work on the other parts where there is no still > agreement. > > Also, I'd like to hear opinions from other developers, although my > impression - from the scattered feedback I read - is that other > developers have the same feeling as me. > > In general, having different channels for different targets would be > ideal, e.g. for articles and tutorials. For this it would be ideal to > have a blog entry for the project org, to simplify contributions from > contributors who don't want to setup a blog just for that and to > collect resources in a single place. In practice we lack this so this > is not an option at the moment (and the wiki is not the ideal place > too). No problem about the delay, although my thinking has moved on a little (e.g. it turns out GIMP uses the word "context" in a completely different way than we do[1]). But rather than argue over today's minutia, here's a big picture idea... It sounds like your vision is for smaller, more disparate documentation; and you're willing to spend some time writing that up. How would you feel about taking the AVClass/AVOptions bits from this document, and working them in to the existing AVClass/AVOptions documentation? That would require a level of experience (and commit access) beyond what I can offer, after which we could come back here and uncontroversially trim that stuff out of this document. For inspiration, here are some uninformed questions a newbie might ask: * (reading AVClass) does the struct name mean I have to learn OOP before I can use FFmpeg? * (reading AVOptions) if the options API only works post-init for a subset of options, should I just ignore this API and set the variables directly whenever I like? [1] https://developer.gimp.org/api/2.0/libgimp/libgimp-gimpcontext.html _______________________________________________ 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".