Hi On Tue, Apr 09, 2024 at 03:57:02PM -0500, Romain Beauxis wrote: > [Apologies for continuing the conversation, Rémi] > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin <g...@haerdin.se> a écrit : > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis: [...] > > > Also as someone who had to maintain a Gitlab instance at uni for a > > couple of years, I agree with Rémi's points > > > > My initial contribution was motivated by the argument presented in the > original talk that bringing new blood is critical to the survival of the > project. > > If so, then I do believe that there must be a compromise to be made between > being easier to join for new developers and changing the existing workflow. > I'm also aware that changing the existing workflow has been discussed > before. > > I don't think that media is not cool anymore, as argued in the talk. I see > a _lot_ of interested developers in my other projects and all over the open > source landscape. That's why I believe that it's also important to consider > other reasons than the talk's argument.
To bring some of the new blood into the project the project needs to first understand why they dont. And asking thouse who manage with difficulty to join could be a biased oppinion. How many potential new developers do we reach, how many of them want to join? how many try to join, and what are the true reasosn for thouse who do not want to join or try and fail? Do we even try to attract new developers ? I think on a scale from 1 ro 10 we are maybe at a 2 when it comes to new developers, theres alot we could do, theres a alot we should know, a lot we could try. The effect on existing developers also must be considered Also even within the current developers there is friction. Solving this friction would increase the number of active developers. And if its not solved then i think maybe we are missing the problem because gitlab even if it adds more people will also increase these frictions even more. Because there are problems between people and not just a email vs gitlab one. What i belive would help is a way for people to develop modules (codecs, demuxers, muxers, ...) externally. That can be a plugin system, it can be something else That way each group can use the development and patch submission systems they prefer. I think the problem we have is less one of aging developers who want new people to come in and the tools being a problem. But instead the old developers having increasingly rigid oppinions that both old and new developers do not agree with. The solution here is to put some space between developers so everyone can work on what they like using whichever enviroment they like. While still somehow maintaining common communication Consider this also in abstract terms In an enviroment where everyone can block and object to everything (at least temporary) the number of potential disagreemnets will grow quardatically with the number of people. This is not scalable Now people certainly can work on their own fork but then users cannot use it or combine these. Plugins would be one fix for this A Decoder is a module that takes a 1-D list of bits and outputs 2-D array of pixels or several 1-D list of audio samples. That interface is not so complex that it needs to be kept inside a monolithic repository thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange
signature.asc
Description: PGP signature
_______________________________________________ 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".
