When a new version of IPFire is released and bugs are discovered, will the update download file be patched with the fixes, will we have to wait until the next release, will we have to find and apply solutions from the forum ourselves, or will there be a patch file that corrects the bugs?
We will not do changes to the Released Core Update iso and image file generally as that can then end up with two versions of the same CU in varying mirrors and we don’t want to have that as that can create more issues such as how to identify which mirrors have which version.
Small fixes that can be implemented into the update process from one CU to the next CU may be able to be done.
Reverting an addon, as was done with clamav, is feasible as that is separate from a Core Update release, although the addon updates are normally associated with a Core Update.
If the bug is a bigger bug and requires significant changes then it will likely be implemented into the next Core Update (presuming the fix can be identified in the intervening period to the next Core Update).
This is why we try and encourage evaluation of the Testing Phase of each release as any issues found during that period can still be relatively easily implemented before going to the Release Phase and then no workaround fixes need to be manually applied by users as the fix can be implemented into the Testing branch.
Sticking in an extra Core Update is not feasible as when a Core Update goes to the Testing Phase the next Core Update starts getting all of its update and development patches merged already. So there are already a large number of commits merged into CU200 (around 117) and trying to change that to allow some interim update would just not be feasible in most situations.
5 Likes
It’s feasible, but it requires much more complex configuration management.
In my previous life as a developer, we knew how to manage multiple parallel versions of the same project and add bug fixes between versions.
Yes, but we don’t have the resources for doing that.
5 Likes
And delay the releases for having a longer staging period for allowing more bugs/regressions/unwanted iterations to be caught?
IpFire for release is more a firmware than a distro, because the updates are not granular at all.
IpFire showed several times that not following the release timeline might be a bad idea, if the installation remains two or three versions back.
Please, consider these occurences might be evaluated as riskier environment compared to other network products.
This 
I cannot emphasise enough how important it is for us that we are getting testing feedback from the community. Whenever we release an update for testing it is definitely stable enough to be installed. If there are any bugs we want to find them then and we will fix them.
Once an update has been released, we will only make changes in very severe cases. In case of Core Update 199, I am not sure if the problems were actually severe enough to warrant the time that has to be put into fixing them.
So, please help us testing.
Core Update 199 has been available for testing for an unusually long time. We normally are aiming for around two weeks, but in this case, the release has been available from Nov 25. There really is no way to make this even longer.
4 Likes
Ok, i hear you but.
Please, take a look at the calendar. It was a wednesday of last week of november; after the testing release there was
full week
shorter week due to 8th of december
full week
Christmas week
New year week
Epiphany week, which was the one of release.
On one hand the time was not that short, but with this sequence of holydays… on one hand some sysadmins already took time for maintenance and testing. But many other persons would not consider that, and found only the “released, so it’s good” 199 core update.
As pure daycount you’re indeed correct, was a lot of time.
On human day count that was not that much, IMVHO; the project have some data on how many installations are out there (FireInfo) and the size of the tested machines/installation for every release.
I’m aware this falls int o”hindsight evaluation”, I hope that this will be considered input for improving, not bashing developers or the project.
Pike,
I am not going to go through all the details about what the release schedule was and what it could have been with you. This is all in the past.
The bugs that have been raised were introduced into development many months earlier. There has been plenty of time to find them, but it didn’t happen.
Core Update 199 was originally planned to be released before Christmas and we already postponed it. Despite all the holidays and all the time of that you personally might have taken, the world keeps moving on.
For me there is no hindsight evaluation. This is under no circumstances a bad release. There have really not been any severe bugs. Actually, the only deal-breaker has been that virtual machines did not start any more. This is implemented as an add-on and by far not a core feature of IPFire. The people in our community who want this feature will have to ensure that they keep it well tested and there bug-free. If that cannot be provided I would be very happy to remove the feature. If we cannot support it well, we should not have it at all.
I don’t know what you are insinuating needs improving here, but I welcome your testing feedback in the next release cycle since the holidays are finally over.
8 Likes
Hi Everyone,
Please, no, don’t let the QEMU add-on die; otherwise, I would have to reset up everything here 
. I am not really getting the issue; everything is open source, and anyone can do their own changes and fixes. I mean my issues got fixed in like 1 or 2 days and i did not even had to talk to L1 support level, a dream. Yes, that is not the convenient way, but @pscar13, you can compile IPFire yourself and add any fixes from the dev branches into your setup anytime. And manage your own versions. Or as the good old developers once told me, “What do you mean the documentation is missing? The code is the documentation, duh.” I mean, these folks are using their free time for the project. Did you do that in your past life as a developer?
Hope this gives an idea why open-source developers like Curl vs AI with Daniel Stenberg | Open Source Security are not that keen to work on such feedback.
Sorry if i upset anyone but any good sys admin i know would have a test system and update to version n-1 just to be safe.
3 Likes
I only make personal modifications for testing purposes, but I always use the official version in production.
It would be too cumbersome to have to recompile modifications for each version.
However, I do use a production ISO test setup to verify test and production (pre-production) updates before installing them.
As any serious system administrator should do.
I only use IPFire at home 
2 Likes
Hello,
Using this topic for a related question: what metadata in bugzilla should I use to track all bugs for a specific CU version?
At the moment I am using the launch dates www.ipfire.org - Welcome! to create a bugzilla search filter like “Creation date: (is greater than)” date of the CU was released.
Thank you!
PS: AI suggested to use “Target Milestone“ or “Version”, but after allowing AI to read bugzilla search page the response was that IPFire bugzilla does not use those as metadata for a specific CU version. Therefore my question above…
Just upgraded from Core 198 to Core 199. The only thing i need to change was in /var/ipfire/wlanap/settings changing DEBUG=4 to DEBUG=0, wifi running ok, tshark running ok, clamav running ok, qemu not installed.
To be able to test better in the future, I will set up a separate mini PC with the IPFire Testing Tree tomorrow. In my VM test setup, for example, I couldn’t test hostapd because Wi-Fi wasn’t available.
3 Likes