| |||||||||||||
RHEL 6: already obsolete ?RHEL 6: already obsolete ?Posted Apr 22, 2010 3:04 UTC (Thu) by lwkejrlej (guest, #64237)In reply to: RHEL 6: already obsolete ? by airlied Parent article: RHEL 6 beta version available
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.
(Log in to post comments)
RHEL 6: already obsolete ? Posted Apr 22, 2010 3:37 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Such assumptions often turn out to be incorrect. Evolutionary releases tend to introduce enough new bugs as well. This is especially the case for desktop environments and large and complex codebases like Openoffice.org. Also importantly, even minor changes in the UI cause alarm from enterprise customers who really don't like change (except for the features they really want but that is another story).
RHEL 6: already obsolete ? Posted Apr 22, 2010 7:41 UTC (Thu) by evad (subscriber, #60553) [Link]
Of course, this would seem to suggest that you assume that evolutionary releases are introducing more bugs than they fix with each successive release. I'm not sure that this is not the case, otherwise software would simply get worse and worse over time, when I've found that software such as GNOME and (Linux) gets more reliable and stable over time.
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.
RHEL 6: already obsolete ? Posted Apr 22, 2010 8:21 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
"Of course, this would seem to suggest that you assume that evolutionary releases are introducing more bugs than they fix with each successive release"
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.
|
|||||||||||||