[NTLUG:Discuss] Heads Up -- Suse 11.1 BAD Idea

[Chris Cox]

On Wed, 2009-01-21 at 13:51 -0600, David Simmons wrote:
> 
> > If it worked in older SuSE versions chances are it will work in the
> newer
> > ones as well .
> 
> Disagree 100% with you on
> this....that's the whole thread on the blog, example after example of
> hardware that used to work, but doesn't in 11.1   The point is
> that something has really gone wrong in the QA department on this
> version.....and like one guy said, "Use the LiveCD of 11.1 and make
> sure stuff works BEFORE changing to this distro".

Actually, there really isn't a QA dept.  This is openSUSE (OPEN)
and it's a community assembled distribution.  There really isn't
a QA except what the community early adopters discover.  And...
since this is free software and open source, sometimes things
no longer work because the original source has changed or no
longer supports something... keep that in mind as well.

> 
> I'm also
> 'stung' by this whole issue and can site very specific examples of (recent
> / should work) hardware that used to work in SuSE 10....through
> 11.0....but now doesn't.

I have things that worked well in 10.3 that didn't in 11.0 (and on and
on).  This is the cost of the free distros.  The more people with
different configs that can test before release the better.... but
obviously, the testers are few and generally don't have access to
a lot of different hardware configs.

Now... let's say a new company was formed that did nothing but
take the early betas out for a spin on a plethora of different
hw configs.  Would you be willing to pay $30/mos. to ensure
that company's survival?  I'm just pointing out that it's expensive
to have a dedicated test team and test center.

So... you either have to join the community of testers... or you
need to consider how to sponsor a test center (that test center
idea was strictly a made up one... so if you send me $30/mos...
I'm not sure what you'd be getting).

The alternative (which is what most people do), is to submit
a bug report so that the fix can make into the next version
and be patient (while trying workarounds, your own compiles
and fixes, etc.).