On Sat, Mar 23, 2013 at 4:18 PM, Kevin Krammer <kram...@kde.org> wrote:

> On Saturday, 2013-03-23, dE . wrote:
>
> > Cause of this behaviour of distros, KDE gets less chance to get tested.
> The
> > only solution is to elongate the release cycles, that way, each version
> of
> > the DE gets tested slowly by every advanced users; so they face and
> report
> > bugs before the very end user face them.
>
> I am not sure I understand this fully, isn't this what already happens?
>
> Due to the way of how distributions undergo their development cycles it
> effectively already increased the testing phase for software they contain.
> First each software is tested by the respective community's beta testers,
> then
> each software is tested even more widely by the distribution's beta phase
> and
> after that by its early upgraders.
> I would guess that at the point a normal user upgrades the software has
> been
> in testing for a couple of months, maybe even half a year.
>
> Lets have a look at the most recent version
> KDE SC 4.10 Beta 1 tag was in November 2012 at which point it is most
> likely
> tested by KDE beta testers. This continues until February 2013 (about three
> months).
>
> If we take openSUSE as an example distribution, its respective release is
> March 2013, adding another monthof testing by people who build from source.
> The test audience at this point has expanded to include early upgraders of
> openSUSE.
>
>
What about beta2?

As stated before, the best way to find bugs is constant usability testing.
Beta 1 and beta 2 have a few days in between releases, so what do you
expect these testers to upgraded every day and yet use their system
normally? Instead they attempt to just see if everything works externally,
and upgrade to the next beta. The same happens with RC releases. These
frequent releases cause confusion. By the time you find a bug for RC1, RC2
is already out, and the devs in the bugzilla will ask for you to upgrade.
Who has that much of patience?

If you want constant usability testing, the target userbase should be
somewhere between devs and end users; these people want a usable system,
and don't mind testing. But for that to happen the releases should be slow,
so it reaches them and it's convenient to them.

The current schedule adds a lot of workload.

Also real testing starts with RC after the freeze -- which ensures no new
bugs. But unfortunately, there's not even a month between RC3 and the
freeze -- how do you expect to find new bugs in a few weeks?

The final (stable) release is hurried up for January; so what do you
expect, a rock solid DE?

Instead there should be 3 or 4 months between RCs, so bug can be collected
and the RC releases reach across layers of users; it shouldn't happen that
before the release reaches the user, it becomes outdated by 2 other
releases.
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Reply via email to