2013/3/25 dE . <de.techno@xxxxxxxxx>:
>
>
> On Sat, Mar 23, 2013 at 4:18 PM, Kevin Krammer <krammer@xxxxxxx> 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?
Usually in KDE bugzilla, dev will ask result of new release to check
whether it is already fixed. This will not mark the bug resolved. So
the bug is till valid. If I am wrong for your case, give out the bug
number so we can check.
>
> 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.
Parden me? I do not see the logic here. You are requesting:
1. Do not release
2. RC version reach large user base.
Are you suggesting distros release RC versions to normal users. I do
not know any major distros regually release RC versions to stable
repo.
If you want large user base test, release it. That is the exactly
reason behind "Release early".
>
> 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?
Check http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule and
understand the schedule and commit policy before putting more miss
understanding here. In short, there are Beta1, Beta2. Lots of Arch
user do upgrade to when they hit [kde-unstable]. See:
https://bbs.archlinux.org/viewtopic.php?id=153419
>
> 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.
___________________________________________________
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.
