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