Each Fedora release is supported for a given time period. Approximately one month after Fedora release X+2, Fedora release X will go end of life (sometimes called EOL). Fedora 25 was recently released, so Fedora 23 will be going end of life shortly. The part of end-of-life that most users notice is that there are no more updates released. Another aspect of end-of-life is cleaning up bugs filed in Bugzilla. An automated script is used to close all bugs that are still open for an EOL release. The goal of closing EOL bugs is to make overall Bugzilla management easier and make sure the right bugs are getting attention.
Reporting a bug and seeing it closed without being fixed can be a frustrating experience. One aspect of open source many people like is being able to report bugs in a transparent manner. However, there are many more users than developers and maintainers. And there are more people reporting bugs than fixing them. Package maintainers may not have time to respond to, or the knowledge to fix, every bug. Maintainers will usually make an effort to report the bugs directly to the upstream project for the developers to fix.
Once a bug is reported to the upstream project, several things can happen. Sometimes a bug is known and fixed, but the developer just doesn’t respond to the bug report. In addition to fixing bugs, developers are constantly working on new features. Sometimes new features will fix an existing bug as well. If there are many changes in a new package version, it can be difficult to identify which change might fix a bug. It is faster for both a package maintainer and developer to request testing on the newest version. Marking a bug as EOL is an indication that the newest version needs to be tested to see if the bug is still present.
If an EOL bug is still present after testing on the newest version, it is appropriate to reopen the bug and change the version where the bug is still present. This is helpful to maintainers, since it lets them know a bug is still present. A maintainer may make different choices about what bugs to continue reporting upstream if they know a bug is still present. By only having bugs open to supported versions, it’s more likely the maintainers and developers will be able to fix the correct problems.
Some packages may choose to do mass end-of-life notifications more often than once a release. The kernel package does this for every major update (updating from 4.x to 4.y). Closing out bugs for versions that are no longer supported helps make sure maintainers see the correct problems. Filing bugs for the latest version of software makes Fedora a better product.
Unfortunately, that’s not how it works from the user perspective. When a bug has no activity for a year, no notes to state that the bug was refiled upstream nor any requests for information, that bug data is lost. There’s no ability to refile the bug because after that much time the user has given up on it ever being fixed and has found some alternative or workaround.
I don’t see any solution to this problem, other than, perhaps, more people stepping up to be maintainers so none of the maintainers are so overloaded that they cannot respond to a bug report for a year. Can Fedora do more active recruiting?
I would gladly volunteer to contribute, however, the stuff taught in my University seems irrelevant.
(Ex: Array of objects, ArrayList, File IO, Inheritance, Polymorphism etc.)
Thanks for this 🙂 helps clarify
Thank you Laura for explaining this, I had always been frustrated by EOL bugs until I understood the process. So the answer here is to check upstream for a similar bug, or at least check Fedora X+1 to see if it was fixed there.
Ultimately, if a bug is really a showstopper it will be fixed in a timely manner. This is another idea for users to think about. If no one fixed it in your Fedora X, there is likely a workaround that you already know about.
I’ll be focusing on the bigger picture now. After all, this is free! The benefits far, far outweigh the bugs!
Can you still update to Fedora 24 even if Fedora 23’s EOL still has package dependencies that haven’t been resolved?
I’ve been waiting for the fix for Digicam, Darktable, etc. that needs dependence of lensfun fixed. Bugzilla Bug 1400242.