The road to 4.3

[Aaron J. Seigo]

On Saturday 03 January 2009, Tom Albers wrote:
> Hi,
>
> I've put up a schedule for 4.3.
>
> As we have Akademy on 3rd of July, I've planned to have released RC1 by
> that date, as we branch at that stage, trunk is open for features during
> Akademy.

sounds great.

> I've cancelled the Alfa release, as it brings almost no feedback. We can
> add it to the schedule later on when we see some massive code changes in
> 4.3, which warrants an extra release.

agreed

> http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule

question for developers, perhaps: how did they find the 6 weeks of beta and 
bug fixing this time around? enough time, not enough time, too long? how about 
the number of betas made?

it would be great if we could get some feedback from developers (e.g. a small 
online survey) regarding things like this.

after 4 months of feature dev, spending 1.5 months not doing feature dev 
(counting from the start of beta1) was a bit of a long singular chunk, but had 
value.

a month between betas, however, was really unfortunate for us in plasma. 
within the first week of beta2, we had the bulk of issues reported and 
subsequently fixed. week 2 saw some more fixes, but far fewer new issues 
(though no end to the reporting =), but by week three reports coming in were 
nearly all duplicates, and fixed dupes at that.

it would be great if we could do a beta (or whatever you want to call it) 
every two weeks to allow for a faster test-fix-test cycle during the 
stabilization (non-feature-dev) period of the cycle.

apparently a huge % of our reporting testers these days are using binaries and 
not building from source, so this really impacts the ability for people to 
test fixes, find regressions introduced by those fixes and report new issues 
that were obscured by the previous problems.

of course, this could be unique to workspace type apps like plasma and other 
apps may see no real value in quicker test-fix-test cycles.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20090103/c9f2aa9f/attachment.sig