2009/11/19 Per Jessen
Rob OpenSuSE wrote:
2009/11/19 Per Jessen
: Rob OpenSuSE wrote:
2009/11/18 Carlos E. R.
:
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, running 11.2.
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 installer bugs. 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 screen?
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. Rob -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org