FFmpeg 5.0
github.com
FFmpeg 5.0
1–10 of 31 posts
Re: FFmpeg 5.0
#2Why is ffmpeg still using Trac for bug reports? Switching to Gitlab would make it a lot more pleasant to deal with.
Re: FFmpeg 5.0
#3In 2003 or 2004 I had a job doing video installations with Linux systems in a variety of museums. That was the first time I learned about FFMpeg. Used it for everything, still one of the first things I install on any system, and whenever I need to do anything with video conversion or resizing or taking a slice out, I use FFMpeg. It is awesome.
Although, after all these years I still have to look up every single incantation except for the most basic things.
Re: FFmpeg 5.0
#4So... what is so much different about it from 4.x?
Re: FFmpeg 5.0
#5Why is ffmpeg still using Trac for bug reports? Switching to Gitlab would make it a lot more pleasant to deal with.
don't know Trac, but can you import your history from it into Gitlab?
Re: FFmpeg 5.0
#6Re: FFmpeg 5.0
#7Why is ffmpeg still using Trac for bug reports? Switching to Gitlab would make it a lot more pleasant to deal with.
Most open source projects stick with the same system they started with. Don't fix what ain't broke.
Re: FFmpeg 5.0
#8Why is ffmpeg still using Trac for bug reports? Switching to Gitlab would make it a lot more pleasant to deal with.
Most open source projects stick with the same system they started with. Don't fix what ain't broke.
Except it is broke. I'm not motivated to deal with Trac even if I want to submit a bug report.
So the above argument is not addressing the situation. Making bug reporting a better experience is in the interest of the project.
I find Debian bug reports a similarly annoying experience becasue it's so archaic. I.e. I deal with it, but I can totally understand if someone is turned off by the experience and simply avoids reporting bugs because of it.
Re: FFmpeg 5.0
#9Cutting releases of such a huge project with so many moving pieces, sub-projects, and dependencies, must be quite an effort!
This "5.0 release" thread in the official mailing list shows that they are trying to establish a "feature freeze" process in order to have a clear cut point where a release branch is made:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-January/290665...
(yes that's the beginning of the thread... I guess the conversation drifted naturally from some previous patch discussion, until the point someone decided to change the email subject)
Re: FFmpeg 5.0
#10Earlier quoted context omitted.
Most open source projects stick with the same system they started with. Don't fix what ain't broke.
Except it is broke. I'm not motivated to deal with Trac even if I want to submit a bug report. So the above argument is not addressing the situation. Making bug reporting a better experience is in the interest of the project. I find Debian bug reports a similarly annoying experience becasue it's so archaic. I.e. I deal with it, but I can totally understand if someone is turned off by the experience and simply avoids…
Making code contribution a better experience is in the interests of the project, making it easier to report bugs is not such a clear win. Consumption-centric interactions are a modern concept originally popularized by the structure of the GitHub UI. Gamifying project popularity and making it easy for users to report bugs nobody is paying to have fixed has almost nothing to do with the actual task of developing software, although (cough) both are convenient if your primary use of open source is as a marketing tool.
I'm sure Marshall McLuhan would have a few things to say about GitHub if he were alive today.