Although, after all these years I still have to look up every single incantation except for the most basic things.
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:
(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)
I just looked at the new features for 5.0.
Does anyone have a more detailed description on what these are?
I'm not sure if ffmpeg follows semver at all. I thought their API was pretty stable after the big change from "next_video_frame" (or whatever it was called) to the send/receive packet/frame model.
Could you explain what you did see in that link in a few simple words?
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.
I'm sure Marshall McLuhan would have a few things to say about GitHub if he were alive today.
I think more projects suffer from under reporting of bugs than from too many bugs reported.
And if no one is fixing bugs, then the above doesn't matter anyway.
You (well, maybe not you, but one) can also imagine all kinds of counter-arguments (not that I know if any of these are true or not):
- Devs would rather spend their time on development
- No one is inspired to move the system over
- They have automations or conventions built on Trac
- Their super users (prolific users, testers, and engineers) are all used to Trac
- People use RSS feeds (Trac has lots of RSS feeds) to stay informed or build other tools, which would all have to be migrated and might have incompatible formats
I encourage you to be more open-minded about the way others choose to work. We shouldn't overemphasize homogeneity in work processes. I also encourage you to be more generous with the words you choose.
All projects can have practical limitations and migrating the bug tracker is still work of course. But ignoring or even denying the fact that current experience is far from perfect is wrong.
For a mature project such as FFmpeg, migrating to a new bug tracking system may produce some value to a small set of people who are reporting bugs, but for the vast majority of FFmpeg users, it produces no value.
So in this particular case it seems like they are willing to sacrifice the convenience of a small subset of users in the interest of the whole user community.
This applies to many mature and long running projects.
Those who report bugs might be a smaller portion, but projects need them I'd argue way more than those who use and never report anything to them.
But I guess someone else has already done it https://451.sh/post/tracboat/