[FFmpeg-devel] Project orientation

[Manolis Stamatogiannakis]

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.ffdev at 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 <george at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".