[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Paul B Mahol]

On Sun, May 5, 2024 at 10:14 AM Rémi Denis-Courmont <remi at remlab.net> wrote:

> Le lauantaina 4. toukokuuta 2024, 23.35.34 EEST Michael Niedermayer a
> écrit :
> > now compare to the linux kernel
> > It uses mailing lists
>
> Sorry but that is at best misleading, and at worse, plain wrong.
>
> The top-level work flow for the Linux kernel is neither mailing list, nor
> web
> forge, but CLI pull/merge. The mailing list is used to discuss and to
> notify
> pending merge requests.
>
> As far as I know, some subgroups still use mailing list for actual patch
> submission and review, and some subgroups have already switched to web
> forges.
> And there are people complaining about the difficulty and exclusivity of
> the
> mailing list-based flow.
>
> > linux is not affraid to innovate to abadon tradition where new things
> > need to be tried.
>
> Well, yes, and accordingly some of the Linux maintainers have switched to
> web
> forges, AFAIU.
>
> > linux is strong as ever
>
> This is hardly a point of comparison. Linux gets support from hardware
> design
> and vending companies as well as from large users. Linux is pretty much an
> exception more than a rule in the overall OSS ecosystem.
>
> If you want to compare FFmpeg, take a low-level middleware project of
> similar
> age and size. For instance, QEMU switched to Gitlab.com a few years ago.
>
> > If you want to be like linux you need to be like linux.
>
> FFmpeg cannot and never will be like Linux. This is a silly argument.
> Nobody
> suggested moving FFmpeg to a tiered merge flow like what Linus Torvalds
> uses.
> The scale and scope of Linux is just so much larger.
>

Merge SDR into FFmpeg, FFmpeg scale and scope, suddenly becomes now much
higher than it was before.

If the project wants to stay relatively relevant and absolutely non-obscure
than it shall just keep continuing current policy of not accepting real new
features,
like native decoders and native demuxers and native filters, and keep only
funding maintenance work, also keep gate-keeping certain contributors,
also splitting contributors into different groups and polarizing those
groups by valuing them differently,
also associating some project contributors into new agencies where
contributing values back to the project is not main factor,
also doing questionable refactoring of working code with results of
questionable performance changes and questionable refactored code design
and quality,
also generally ignoring regressions and new or old bug and feature-request
user's reports,
also leaving the project fast without any notice for selfish reasons,
also using communication prone to different interpretations,
also not valuing new research and better and faster algorithms,
also still associating self as the project developer when major last
contribution to the project was in previous decade,
also not properly valuing writing native solutions that are better than
current state of art available in open source or in general,
also using real-life meetings between selected contributors for ensuring
unrelated personal business growth and/or increasing self net-worth for
selfish reasons,
also using obscure social-channels while attempting to raise the project
relevance and ensure future funding for the project to keep personal
business alive,
also not maintaining current infrastructure and investing in new
infrastructure to reduce new regressions and bugs popping up,
also labeling and name-calling and discrediting other contributors and even
their work for selfish and short-sighted reasons,
also accepting only some radically and obscurely strict technical process
of contributing and also labeling and alienating developers and developing
process non-conforming with that technical process.

This is the project recipe for success and relevance growth and fast
advance in popularity and real progress moving forward and for healthy and
prolific project future at all dimensions and fronts.


>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>
> _______________________________________________
> 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".
>