Mailinglist Archive: opensuse (3605 mails)
| < Previous | Next > |
Re: [SLE] Re: And another 10.1 showstopper
- From: "Bryan J. Smith" <b.j.smith@xxxxxxxx>
- Date: Thu, 01 Jun 2006 23:44:10 -0400
- Message-id: <1149219850.23886.111.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Thu, 2006-06-01 at 22:19 -0500, Rajko M wrote:
> One possible solution for vendors showed Conexant (modems). Making
> agreement with Linuxant they have Linux driver that is self financing
> operation.
Here's my last comment on the matter ...
There is a _difference_ between quality assurance just on an
_individual_ software project basis, and integration testing multiple
pieces of software as a whole _distribution_. While you can often do
effective integration and regression testing of a piece of software on
its own, with the immediate software it is designed to work with or rely
on, you can't possibly address all the countless combinations of
software that people will throw at a distribution.
There's only so many systems and combinations distributions can put
under test in-house and in-beta before release. It's only when you
finally release that you run into software combinations that were never
expected. And they are software combinations that had nothing to do
with the original intent of the distribution.
Those distributions that adopt newer APIs and software versions will
definitely have more issues upon release -- even if they fully develop,
integrate and regression test all the components that ship in the
distribution itself. Red Hat has been infamous on this -- forcing
people to move to various APIs.
GLibC 2 (Red Hat Linux 5.0), ANSI C++/GCC 3 (Red Hat Linux 7 and,
subsequently, RHAS2.1/RHEL2), NPTL (Red Hat Linux 9 and, subsequently,
RHEL3), SELinux (Fedora Core 3 and, subsequently, RHEL4), etc...
All of these software packages were fully integration and regression
tested in their distributions _before_ release. But they were
definitely going to cause issues with _other_ software integrated with
the software _after_ release. They weren't "broken," but they were
definitely "causing issues" as the result of adoption and their
_inability_ to support some legacy code/interfaces/etc...
Sometimes you have to just adopt something for people to move in the
right direction.
After all, some people are still bitching about Red Hat Linux 5.0. ;->
Despite the fact that moving to GLibC 2, away from the old, and security
nightmare LibC4/5 forks from GLibC 1, was one of the best things.
--
Bryan J. Smith Professional, technical annoyance
mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com
-------------------------------------------------------
Illegal Immigration = "Representation Without Taxation"
--
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx
> One possible solution for vendors showed Conexant (modems). Making
> agreement with Linuxant they have Linux driver that is self financing
> operation.
Here's my last comment on the matter ...
There is a _difference_ between quality assurance just on an
_individual_ software project basis, and integration testing multiple
pieces of software as a whole _distribution_. While you can often do
effective integration and regression testing of a piece of software on
its own, with the immediate software it is designed to work with or rely
on, you can't possibly address all the countless combinations of
software that people will throw at a distribution.
There's only so many systems and combinations distributions can put
under test in-house and in-beta before release. It's only when you
finally release that you run into software combinations that were never
expected. And they are software combinations that had nothing to do
with the original intent of the distribution.
Those distributions that adopt newer APIs and software versions will
definitely have more issues upon release -- even if they fully develop,
integrate and regression test all the components that ship in the
distribution itself. Red Hat has been infamous on this -- forcing
people to move to various APIs.
GLibC 2 (Red Hat Linux 5.0), ANSI C++/GCC 3 (Red Hat Linux 7 and,
subsequently, RHAS2.1/RHEL2), NPTL (Red Hat Linux 9 and, subsequently,
RHEL3), SELinux (Fedora Core 3 and, subsequently, RHEL4), etc...
All of these software packages were fully integration and regression
tested in their distributions _before_ release. But they were
definitely going to cause issues with _other_ software integrated with
the software _after_ release. They weren't "broken," but they were
definitely "causing issues" as the result of adoption and their
_inability_ to support some legacy code/interfaces/etc...
Sometimes you have to just adopt something for people to move in the
right direction.
After all, some people are still bitching about Red Hat Linux 5.0. ;->
Despite the fact that moving to GLibC 2, away from the old, and security
nightmare LibC4/5 forks from GLibC 1, was one of the best things.
--
Bryan J. Smith Professional, technical annoyance
mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com
-------------------------------------------------------
Illegal Immigration = "Representation Without Taxation"
--
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx
| < Previous | Next > |