Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Stability v. security fixesStability v. security fixesPosted May 10, 2007 8:12 UTC (Thu) by addw (subscriber, #1771)In reply to: Stability v. security fixes by mjcox@redhat.com Parent article: Stability v. security fixes
The only reason why you may want to delay outputting a fix is if it might break something else; ie the fixed version is in some way incompatible with the previous version.
I would really doubt that the fixed cpio would break any backup/... script, so what is the harm in releasing it?
One of the reasons for paying for RedHat is the nice warm feeling that you are being looked after. If fixes are delayed like this you are allowing a cold draft into the blanket.
(Log in to post comments)
Stability v. security fixes Posted May 10, 2007 14:50 UTC (Thu) by uravanbob (subscriber, #4050) [Link] Actually, my industrial customers see ANY change as a requirement to recertify the software - this is of course very expensive. It is not always a completely rational view, but then it is their systems that they are making the decisions for. In this case we are talking about security fixes for problems that rate very low on the risk scale - security is very much a risk management game, so as long as RH makes these fixes available to those who feel they need it, I see no cause for complaints other than that RH is penalized in the counting game.
As a developer, it is very frustrating when a user wont apply a patch, however it is even more annoying when a 'minor - should not affect anything' change has major consequences because well, we're human and screwed up somewhere.
Stability v. security fixes Posted May 10, 2007 17:06 UTC (Thu) by dlang (subscriber, #313) [Link] the complaint people are makeing is that RedHat didn't make these patches available for a long time (over a year in several cases)
|
|||||||||||