Not logged in
Log in now
Create an account
Subscribe to LWN
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
GNU virtual private Ethernet
RHEL 6: already obsolete ?
Posted Apr 22, 2010 3:04 UTC (Thu) by lwkejrlej (guest, #64237)
By the rather long lists of bugs fixed ? Did the RHEL 6 "QA" address all of the bugs present in OO.org 3.1 that are listed as fixed for 3.2 ? Is Red Hat's QA team the same size as OO.org's development team ?
It can be argued that anything with new features carries the risk of bugs. However, recent OO.org, Gnome & KDE are evolutionary releases rather than groundbreaking or totally fresh codebases, and as such it's much more likely that the amount of bugs introduced is less than the number of bugs fixed.
Posted Apr 22, 2010 3:37 UTC (Thu) by rahulsundaram (subscriber, #21946)
Posted Apr 22, 2010 7:41 UTC (Thu) by evad (subscriber, #60553)
The argument is that staying with the old branch and only backporting just the fixes is a good thing. It works whilst the upstream supports it (usually about 6-12 months) but then you are forced to backport fixes to older versions that were never intended to have those fixes. Things break.
Red Hat have admitted this in person to me during subscription negotiations: Red Hat tend to break things badly by back porting critical bug and security patches (as well as new features). They fix security bugs and then they have to fix the fix because it exposed code paths that were never seen upstream.
So, customers should compare the latest stable versions of the software from upstream with an older version being maintained by Red Hat with new features/fixes (cherry picked ones, note!) backported over the top in a way that was never designed.
As you say, newer releases introduce *new* bugs (whilst fixing old ones) and *new* features. I don't really like the Enterprise Linux releases (they are obsolete at release and the package set is small) or the non-enterprise ones (Huge package set but insufficient testing, lots of new untested features, short lifespan). There has to be some middle ground we can get to.
Posted Apr 22, 2010 8:21 UTC (Thu) by rahulsundaram (subscriber, #21946)
That is indeed possible but not what I am suggesting. What I know instead is that even evolutionary updates introduce *new and different* bugs from the previous version while introducing new features and fixing some old bugs. Red Hat cannot simply just use the latest upstream user space for major codebases like a desktop environment or a office suite as has been suggested here. QA, hardware and software certifications take a lot of time and effort.
This is not to claim that backporting is a panacea but it is a solution that has worked better than anything else for the most part for the target market and Red Hat does update leaf packages like Firefox more often and introduce parallel installable versions of new software like Postgres. In the case of Postgres, some customers want the new features in it but simply upgrading to the latest version is not a option when the new version also introduces incompatibilities.
If more upstream projects would stop introducing so many (often avoidable) incompatibilties and take API/ ABI stability more seriously, it would certainly help but I am not sure there is a definitive movement towards that.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds