Thanks Gerion. This sounds more or less like what I had in mind (but I was trying to keep it short).
– The present thread is a non-technical discussion, and branching indeed helps. The mailing list is perfect for this kind of discussions. – Patches with narrow scope are focused, technical discussion, which is unlikely to branch. They can be dispatched and discussed directly as a PR, either via the web interface or email. This should keep this list more focused. – Patches that involve deeper changes can be discussed before materializing in a PR, in whatever way core developers prefer. To be clear, by no means I am in favour of deprecating the mailing list. PRs and Issues are not a panacea. E.g. asking questions by opening issues on GH/GL is something I would frown upon (and I have seen happening elsewhere). Best regards, Manolis On Thu, 9 Jul 2020 at 12:27, Gerion Entrup <gerion.entrup.ff...@flump.de> wrote: > Hi, > > Am Donnerstag, 9. Juli 2020, 02:56:28 CEST schrieb Manolis > Stamatogiannakis: > > On Tue, 7 Jul 2020 at 16:27, Nicolas George <geo...@nsup.org> wrote: > > > > Is tree threading that important? A PR is essentially a single > thread of > > > > discussion. > > > > > > It is a single thread of discussion until the discussion becomes > complex > > > and has branches. > > > > > > > This doesn't sound like the common case. > > But it should be straightforward to get some statistics on that from the > > list archives when a transition is officially discussed. > > This whole current discussion here would be a lot more confusing without > branches. > > Maybe you like the Gentoo approach: Do the majority of changes in pull > requests, in Gentoo this are changes of packages, here it would be > changes on codecs/demuxers/filters/etc. And then do all changes of the > framework itself and discussions via mailinglist. In Gentoo this are > changes of eclasses (i.e. code libraries for packages). For FFmpeg it > would be the introduction of new API, API changes, decoupling or merging > of libraries etc. > > The first is likely to produce no to little (conflicting) discussion, > has a huge benefit from CI, is the part where most of the newcomers begin > development and includes a lot of easy tasks. Here by far the most > developments happens. > > The latter is likely to produce huge discussions, needs deep knowledge > of the libraries, so it is not likely done by newcomers and has little > gain from CI since it adds e.g. something completely new. Here happens > not so much development in terms of frequency or code lines but the > impact is much higher. > > Just a suggestion, since I follow both projects... > > Regards, > Gerion > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".