On Sun, May 5, 2024 at 10:14 AM Rémi Denis-Courmont <r...@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@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".
