How are (nethserver) bugs handled with subscription enabled?
Since nethserver-fail2ban is now an official module and also in nethserver repos, shouldn’t it be pushed there when there are feature-blocking bugs that interfer with normal usage?
Exactly waht I thought @dnutan .
A known bug shouldn’t be in “stable” repo. If it’s not possible to push the latest version to the subscription repo or the new version is not tested enough or whatever, the buggy version at least should be removed from stable repo.
IMO it’s better to not provide a module for some time, then providing a known bug.
Receiving updates with some days of delay protects against regressions due to upstream updates, but as you can see has the limitation that delays also the availability of trivial bug fixes like this. It’s a trade-off…
In this case the workaround is straightforward
yum --enablerepo=nethserver-{base,updates} update nethserver-fail2ban
I’d like to add a “sb-fast-track” repository to Subscription installations, so that we can easily push immediate availability of fixes like this /cc @giacomo @alefattorini.
3 Likes
I had a look at nethserver-update repo. The version there is 1.0.3 from 27.05.2018.
So it’s clear that this isn’t in stable. Just 4 days.
But shouldn’t the old one (ver 1.0.1) be removed as soon as the bug occurs?
IMO a module with a bug should be temporarely removed from stable repo immediately after the bug is confirmed and be readded when the bug is solved, instead of leaving the buggy module in stable repo as long as the fixed module is released.
I don’t know if there is a written procedure how to handle bugs in stable/subscrition repo.
But if not, maybe it would be worth to think about it, isn’t it?
Bug happens. Always. In the stable repositories and in the testing ones.
More frequently in the latter because are less tested. Said that I agree with Davide:
You can’t have both. But I think that is a special case. I feel like in the future having feature-blocking bugs in the stable repositories won’t happen so often.
We have a new system release, 7.5 out there. Subscriptions are still at 7.4, but who installed a new system during this days gets 7.5 and if registers it with Subscription he gets the new release.
How to deal with this process surely needs to be improved. By the time 7.5 will get more stable we will roll out the system upgrade for 7.4 installations.
But this is a different issue. I think that the problem remains. How to deal with a bug fix or a security fix that needs to be fast tracked to subscriptions? I still think a special repository is required.
2 Likes