2008/12/24 Rajko M. <rmatov101(a)charter.net>et>:
On Wednesday 24 December 2008 05:13:16 am Vincent Untz
> Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
Problems in development release that scare 99% of
1) boot configuration setup is black box, there is no
list of supported (to
that moment tested) boot configurations. Actually there is no public
specification what should go in this list: partitions, file system, permanent
storage, (anything else)
Do you mean specific advice for Factory? Because there is a Wiki page
on what "boot configurations" are known to work reliably eg) small
ext2 in primary or logical partition.
2) kernel will not boot on certain hardware, how to
Reporting this requires a lot of text to be copied, once you make to the
usable configuration. Some simple numeric indicator like line number, or
breakpoint number will help much more. It is easy to note on the paper, and
easy to post. Splash screen during first phase of development that can have
kernel crashes, should be forbidden.
I like the "No Splash!" idea :) Often an older Live CD will boot, and
allow info to be collected, in a pleasant way. Perhaps a special
Network Install disk, with logging set up to go to another machine
would help testers?
3) X crashes, and nothing tells that Failsafe option
offers a GUI (it should
be named "Failsafe Graphic Mode")
Please make a simple obvious way to get to text mode, it may not be
something you'ld market, but it'd be help a lot when sleuthing
troubles, on forum and such.
4) will not log in default desktop, or desktop
crashes, but alternative to
change desktop is in the login screen at the bottom left corner, but how many
will click on barely visible text (kdm). This is good for release. Please
make life of a tester easier, and provide list, not drop down menu,
I filed a Bugzilla on that already (useability).
If you'ld care to check it over and add any comments.
6) Uaesrs need fallback options to usable
alternatives, example is what Knoppix
and derivatives offer on a boot screen. Press function key and get list of
cheat codes, or other kernels that can be used to boot a system. Later, when
all seems to work OK, that can be removed.
Actually yes; GREAT POINT!!!
What is wrong with including the 11.0 kernel on the ISO disk, for the
installation, so that it can work, to the point where the ISO's can
install an updated kernel from the net.
That would reduce the effect of kernel driver regressions.
Development should be focused as much as it is
Today we test new kernel, tomorrow X, or libc, or whatever, and so on.
Having to debug interaction between change in libc and the rest of the system
can mean a lot of work, but it is easier then what we have now.
Yes, I like to have kernel, gcc or glibc change, or new application
software, but not two of those at same time.
It is nice to have many new kernel features included,
but if that means broken
result, what is use of those features?
In old SuSE days, it was not unknown to ship with multiple kernel
versions eg) 2.0 and 2.2; or 2.2 and 2.4.0 kernel (SuSE 7.1).
Probably some testing of skills provided by openSUSE
will help to get a
picture what can be tested by community and what methods and tools have to be
provided as a help. Reliance on unknown number of testers, with unknown
skills will not move us from current status where number of hidden errors grows.
openSUSE isn't responsible for testing all the packages, thoroughly.
Things like gcc, perl, come with a test suite, which aid packagers.
Really the distro needs to do configuration and integration testing.
There's not much point having 100 ppl, installing X.Y into Virtual
Box, and all saying "yes it's fine". Perhaps online update could use
a stored hwinfo/smolt profile, to appeal for testers for the new
release in a more targetted way; rather than have it installed on
Then slow down a bit whole process, please.
I barely had time to download and install some releases and it already was
time for a new one, before I had setup to test with. I don't think that I'm
special in this respect.
That's clear, the schedule discussion and feedback in general from 90%
of ppl is that 6 months is too short.
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org