Mailinglist Archive: opensuse-project (189 mails)

["Rob OpenSuSE" <rob.opensuse.linux@xxxxxxxxxxxxxx>]

2009/1/7 Rajko M. <rmatov101@xxxxxxxxxxx>:
> On Tuesday 06 January 2009 07:40:13 am Rob OpenSuSE wrote:
> > 2009/1/4 Rajko M. <rmatov101@xxxxxxxxxxx>:
> > > On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
> > > > On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
> > >
> > > Situations where something doesn't work are common when you try to
> > > synchronize few thousands software titles. Some configurations will work,
> > > some will fail.
> >
> > This is true, but now how to home in on the problem source, so a
> > solution is found efficiently?
> >
> > Do you?
> >
> > a)  Update and change absolutely everything, and release probably as
> > one huge pile of broken stuff, which then needs a lot of sorting
> > through?
>
> If you update kernel, libc, ( and probably more) or just change gcc options
> than whether you want or not, you have huge pile of broken stuff.

Should that happen, then you know the probable cause, don't you?  If
you've updated applications at same time, then you're looking for a
problem in far more code.

Actually, generally updating the kernel, doesn't break a lot of stuff.
gcc updates might be difficult or not, similarly glibc.  I've got a
SuSE 8.2 installation that can run on a 2.6 kernel for example.

Those effects are actually arguments to move 1 step at a time, if you
find that updating glibc, or recompiling with gcc leads to a huge pile
of brokenness, then you don't implement that change widely, until the
issues are understood and fixes are available.

> > b)  Phased updates, some parts release stable as others change, with
> > only minimal required bug fixes going in to the rest of the system?
>
> Phased updates are possible on software above base, but if you keep base
> stable, many packages can't be updated.
>
> If you don't have support in kernel for certain hardware, then your
> application will be stable and disfunctionall. I'm pretty sure that crashing
> leaves bad impression, but missing bugfixes and functionality is not good
> too.

"stable" doesn't mean frozen.  In the even an application requires an
update to the core system, say a patch to glibc, or a bug fix to
another library, perhaps even gcc, then you should be able to do that.
  Some intelligence and impact assessment about such changes is
required.

Actually new software is generally developed for a while, and does not
require the latest systems to run on; because that would cut down the
end user base.

Missing bug fixes, in a test release is not a huge issue; when you've
explained that the aim is to test out other parts of the system.  If
it's a very important critical bug, then you don't keep the end users
waiting, but effectively do a 'phased' update via a patch, and just
change a minimal part of the system to sort out the bug.  So do that,
rather than worry about known bugs that are also present in the
current stable versions, that end users are using.

> > c)  Many small steps, rolling back 'bad' changes, with one release
> > rolling on and evolving into the next?
>
> Rolling back is in general wanted, but devil is in details.

> > Some method of moving forwards, and rolling back changes; appears to
> > me the best shot at growing tester base, and maintaining sufficient
> > quality for the code to run on real hardware, not virtualised.
>
> In general there must be plan B, to go with A, or bust, is not good.
>
> While it forces people to test, new guys that will attempt installation to see
> how openSUSE works, will be scared away. It doesn't really matter how good is
> openSUSE when it is installed, if it crashes in first few steps in any boot
> option including Failsafe.
>
> I guess that we have to work a bit on scenario where the newest kernel
> crashes. What then? Debugging is fine idea, but having working alternative
> from the boot medium is better to bring masses to openSUSE, which bring more
> people willing to test.

Crashes, I've not seen;  hangs whilst booting when udev starts up.
Problems with screen resolutions and graphics drivers, or being unable
to find the right disk or installation media.

By the time, that kind of user is trying to install openSUSE they
should have a kernel that's been run and tested widely; they ought to
have experimented with Live CDs.  They are not useful testers to a
development release, their bug reports and skills to provide further
information won't be high enough, nor will their motivation to see
through an issue to a fix.



Software is far more modular and more robust, if it's well written;
it's just not true that installing a new version of GNOME with a
certain version of gcc, is going to break perl scripts say, because
the perl interpreter will be interfered with.  The software packages
are independant and rpm's job is partly to ensure there aren't
conflicts, and keep perl & GNOME seperate.
-- 
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx