James Almer (12025-01-17): > I don't see how the GA has anything to do with this when we're talking about > one person, but you're not wrong in that rejecting a feature for being > incomplete is not ideal. > The codebase is not lacking in partially implemented features and protocols, > and as long as it's stable, is not invasive, and gracefully rejects > unsupported scenarios, IMO it should be ok.
How many partially implemented or experimental features can you quote that have been added in the recent years, when the GA has been in authority with the current structure? Last year, there was the software-defined radio proposal. It was big but non-invasive and easy to remove in case of issue. It was rejected with an arbitrary “does not belong in ffmpeg”. It did not go to vote, because it was so obvious for everybody involved that the opponents had the numbers with a wide margin. A little older, that I mention because it is close to me, there was the ground-work necessary for enhancing the utility API: error reporting, built-in documentation, uniform API for different types of objects, etc.: rejected “does not belong in ffmpeg”, would have been a waste of time to go to vote. This last point is what convinced me to stop investing time on ffmpeg as long as the GA has authority: why spend effort when a bunch of people who barely understand the project can send all my efforts to waste because they consider anything that does not profit them immediately and might hypothetically make more work for them? This “it does not belong in ffmpeg” attitude in the GA is killing the project. It needs to stop. We need somebody in charge who understands what ffmpeg really is. -- Nicolas George _______________________________________________ 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".
