Massive Konqueror Regression

David van Hoose david.vanhoose at comcast.net
Thu Aug 18 02:37:24 CEST 2005


Aaron J. Seigo wrote:
> On Wednesday 17 August 2005 04:59, David van Hoose wrote:
> 
>>My point in bringing up this topic was to point out that there have been
>>a lot of regressions in KDE in the last two major versions due to
>>far-to-quick releases.
>>There needs to be a longer freeze with better regression tests.
> 
> 
> mode = repeat;
> 
> what we need are more human testers to test things during the freeze periods. 
> we could freeze forever and there'd still be regressions because too many 
> people wait for the final release and then bitch about things afterwards. it 
> would be nice if some of those complainers became testers.
> 
> there are a LOT of things in KDE that simply can't be regression tested 
> automatically. this is because:
> 
> a) a lot of those items are GUI related and require a human sitting there to 
> watch for things (unless you have a GUI regression tester suite available for 
> use ;)
> 
> b) we lack the resources (see the discussion re: syncing where it's both a 
> time and a hardware issue)

Very true indeed. I helped out with testing KDE 2 and it was really fun, 
but when KDE 3 beta came out, I couldn't spend as much time with it as 
it needed because of all of the bugs. There needs to be a set of 
regressions that are run after developmental changes. This will prevent 
most of the bugs you are talking about from reaching the beta. At that 
point, beta testing will be much easier for the user.
I beta tested Merlin years ago and never had a single problem that 
wasn't cosmetic. But beta testing KDE now is almost like gamma testing 
Chicago. There needs to be some controls put into place to make the beta 
not as unstable as an alpha. Don't you agree with that even the 
slightest bit?

-David


More information about the kde-quality mailing list