On Sun, 27 Jul 2025 at 11:39, Nicolas George <geo...@nsup.org> wrote: > > Kacper Michajlow (HE12025-07-26): > > I don't think moving over is something that requires significant > > effort. It just needs clear communication about this. > > > > Also, I don't think the current ML workflow is very sophisticated on > > ffmpeg-devel, so there are likely not many tools to migrate to the new > > one. > > A statement like that mostly shows a lack of experience with regard to > projects like ours, i.e. projects that started at the time JavaScript > was a bad joke and kept a stable kernel of developers over time.
I'm talking about ffmpeg specifically. ffmpeg is not a Linux kernel, comparing the two is plain ignorance. The fact both uses ML doesn't describe lack of process quality in ffmpeg development. There is no process, no reviews. You are the one guy who fails to recognize the issues that are tried to be solved by employing better tools for productivity and organization for both contributors and maintainers. I don't mean to offend any contributor, but the current ffmpeg development loop is 1) send patch 2) wait a week 3a) merge if you are maintainer without review 3b) get implicitly "rejected" because your patch will be already lost in the abyss There is patchwork which hardly helps with anything. And sure you can have custom tooling to track everything, you probably have. You cannot compare this to Linux development with a strict merge window and release schedule, dozens of separate source trees each governed by dedicated maintainers, and strict policies on how the big machinery is working. And it is working, no one says it is not, but ffmpeg is not comparable to that. > This lack of experience is corroborated by the use of GMail, something > that is to real email what a Palyskool Plastic Toolbox is to a real > tool set. Tools are only good as you use them. If you feel superior for using different email providers that's very cool for you. Instead of insulting and antagonizing people every other day, why don't you use your superior email and tooling to actually help with reviewing patches and implementing code? > Our current setup is in the spirit of Unix: we use multiple tools, each > tool does one job and does it well and interacts well with other tools > that do another job and do it well. These tools can be connected > together to build complex processes efficiently. And what process is that? Those vague guidelines in the "Contributing" document? Also tools are only means to the end, which is development of ffmpeg. Any time wasted using/developing tools is not directly improving ffmpeg. The web forges may not be perfect and employ a certain pipeline of working, but they make the entry point the same for every contributor. > These forges are like Windows. They look nice and work out of the box is > somebody else installed them for you, and simple tasks are very easy. > But they require >50 clicks for any non-trivial task, and if something > went wrong, you have to redo all >50 clicks after fixing it, because you > cannot summon clicks from a command history. Examples. Please be specific. If we know what the problems are we can think about the solutions together. > And if you want to automate because you are fed up with repeating >50 > clicks every time, then your realize that the automation features you > were assured where there only covers a third of the features you would > need, only half of them are properly documented, and half of those do > not actually work as documented. > > On the other hand, every single person who contributed a lot to the > project since a long time have developed over the years our own > workflow, our own automation. It can take many forms: shell scripts, > macros in an editor or an IDE, pre-populating the shell with useful > history lines, etc. Each person's workflow is tailored to our particular > strengths (graphic / verbal / procedural memory, etc.). > > This has let us become very productive. More productive than anybody > would be starting with these forges. Possibly more productive than > anybody could become even after tuning these forges as much as possible > to their needs. > > You are asking us to abandon most of that. "We". The current move is not happening without a reason and not happening on a whim. And is endorsed by most maintainers. I understand fear of a change. Some people are comfortable in their safe space and never want to step forward, even if it constantly takes them backwards. > I suggest you spend time learning better tool instead. Likewise. - Kacper _______________________________________________ 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".
