2009/11/19 Per Jessen <per(a)computer.org>rg>:
Rob OpenSuSE wrote:
> 2009/11/19 Per Jessen <per(a)computer.org>rg>:
>> Rob OpenSuSE wrote:
>>> 2009/11/18 Carlos E. R. <carlos.e.r(a)opensuse.org>rg>:
To me, what is worthwhile testing is something I
determine. It is in no
way influenced by what may or may not have been tested already.
I will often try out the alphas/betas/RCs on boxes I might be prepping
for production, or a box that has been taken out of production, but not
yet moved. Right now I've got a new firewall box sitting next to me,
Yes that's good opportunism.
If 10 people
are using that machine daily as a desktop already, then
it's waste of time duplicating their effort.
Perhaps - doesn't it depend some on what they're doing with it and if it
is _exactly_ the same machine?
Well I have installed Linux for 10 years or so, so when things don't
go smooth I'd like to think I can develop work rounds, and narrow the
problem down. Our releases do not install smoothly on all supported
range of hardware, because of driver issues in kernel, or sometimes
To me those bugs, that stop someone running Online update, are much
more serious than 'normal' application bugs, say a crash in Kget when
you investigate torrents in a download group.
What does the average user do, when faced with a GM release that
simply locks up, when the kernel starts running, or just get a black
It seems clear
from response to this thread as a project, we really
have very little idea really about the range of hardware our newest
release has been tested on.
Yes, I think that is a very safe assumption to make.
We could only start to get a picture as cron jobs
start running on
1st. But don't find it obvious with smolts.org
how to filter out
Fedora etc and only look at results for OS 11.x.
I looked at the smolt package, and AFAICT, Henne Vogelsang added a
requirement for cron back in 2008, so maybe that's when the cron-file
was created too. Maybe Henne had some specific idea wrt the 0120 time
to run smolt?
I used to avoid the sleep issues in a simple way by having the cron
job, create a job with randomised later time into an at(1) queue
configured 1 job wide and like the batch(1) queue to run only when
system load was low. That way the job would get run, even if there
was downtime and you didn't need processes hanging around.
Unfortunately we don't seem to enable at(1)/batch(1) on default
install, so Carlos's idea seems the best suggestion.
If we can't use the info gathered effectively, there seems little
point in taking a look at the upstream code, and writing & trying to
get them to accept a SuSE specific patch which works better with our
dumber cron(8) system.
Unfortunately we've got another bad review on lwn.net
, this time it
installed with disgusting fonts, which would have caused huge fuss on
forum if it were a usual happening. The recommendation is to wait for
11.3, which given how improved past releases were 10 weeks after
release by updates, seems really unfair.
As Joe said, it's is the users/reviewers job to 'blame', and without
something more organised (and the visible collection of smolt data
seemed a step on this parth) to ensure reasonable test coverage (even
just booting of Live CD) I can't see how the GM release will really
improve and become "just works" for more ppl.
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org