Release schedule clarifications

[Torsten Rahn]

I have just arrived from the first two days of Systems fairs in Munich. 
There we collected quite some user feedback as well as experience about how 
current KDE SVN (monday, 23rd october) as well as the openSUSE Beta3+ Live CD 
performed on different machines.

Judging from the experience we gained there I'd like to support the idea of 
labeling workspace + apps "BETA 4" while labeling the API/plattform RC1.

In detail we noticed the following:

- Almost all visitors who had been long-time KDE enthusiasts and were known 
for early feedback in the release cycle had completely failed to participate 
in our Beta program so far (and I know some of these people since about 8 
years). 
Most of them had tried to build the KDE betas, failed to see a desktop / panel 
appearing and therefore assumed that the apps were not worth testing at the 
current stage.
This is rather alarming given that during a late Beta cycle the targeted beta 
testers should have moved from the developers to the enthusiasts.

Therefore the only Beta that gave a chance to participate in Beta testing is 
the OpenSUSE Beta3+ Live CD as this Beta release was the only one that showed 
a start button and a menu. Even the experience of the Beta3 was often dubbed 
as that of an "early Beta" - as opposed to a "late Beta" - which is quite of 
a stretch already. 

I'd also like to point out that so far KDE 2.0 was certainly our most 
problematic release. However even for that one the participation of 
enthusiasts was a whole lot better. KDE 2 RC1 still had rough edges (more so 
than any other release until KDE 4). KDE 4 on the other hand still has got a 
lot of holes (calling it "rough edges" would be euphemism) in addition to the 
rough edges.

While many apps work very well the workspace (plasma) still has serious 
problems in terms of performance as well as quite some gotcha's in terms of 
basic usability. 

So in summary I'm perfectly fine with an imminent API freeze (however that 
part is not my expertise, so I leave it to others to judge about it).

However calling the current state of the workspace +  apps anything beyond 
BETA would be dishonest and would certainly generate quite a bit of 
irritation among press and enthusiasts as it would skew common definitions of 
technical terms in software development extremely.

That all being said the late progress especially with regard to plasma has 
been totally amazing. It's clearly visible that we are getting nearer to the  
release each day and that KDE 4 has got a lot of potential to be an awesome 
release.

However we should avoid to jump the gun to make sure that we won't loose trust 
among enterprise people (who already now _do_ watch KDE 4.0 closely even if 
they evaluate to deploy KDE >=4.1) and to avoid that we generate unnecessary 
bad press.

Torsten


On Wednesday 24 October 2007 16:27:05 Dirk Mueller wrote:
> On Sunday 21 October 2007, Cornelius Schumacher wrote:
> > (all deadlines are due 23:59 UTC)
> >
> > 24 October (Wed): KDE 4.0 Release Freeze
>
> I don`t really like to work in the middle of the night though. I`ve had a
> short look at the state of today, assuming that I`m supposed to tag a final
> release of the KDE 4.0 platform.
>
> These are the current list of showstoppers:
>
> a) it does not even compile (see http://ktown.kde.org/~dirk/dashboard)
> b) even if it would compile, it doesn`t really start up for me.
> b) there is no way currently to define a platform version number different
> than the KDE version number.
> c) kdebindings does not compile ATM
>
> Regarding b), does it make sense to rename the current KDE_VERSION into a
> KDE_PLATFORM_VERSION and export a KDE_WORKSPACE_VERSION (not sure where we
> should get it from, has to be generated from somewhere within
> kdebase/workspace). This would be source incompatible, thought the fallout
> could be fixed pretty easily (unfinished patch attached, just to get the
> idea).
>
> > - Deep freeze (changes only by release team)
>
> I don`t like the "deep freeze" terminology. I would like to have everybody
> else fix the build instead of the release team. Especially those that broke
> it ;)
>
> Also, I find it hard to believe that we want to go from a nearly "ignored"
> Beta3 state to a "4.0 final" state for the platform without a release
> candidate inbetween.
>
> The additional trouble is that the new release schedule asks for a
> kdebase-runtime tarball, which does not exist yet. So I first have to
> create one and that is probably not easy in the first try. That alone
> justifies a release candidate for me.
>
>
> So, my current plans are:
>
> a) fix the build
> b) sort out the version number mess.
> c) do a release candidate build tomorrow morning.
> d) decide on the feedback (which hopefully comes :) )
>
>
> Another issue that doesn`t seem to be solved so far is that we don`#t have
> a clear list of things that are just there that are going to be deprecated
> with the 4.0 release (kjsembed? khtml? kjs? plasma layouting stuff which (I
> heard rumours) is going to be deprecated with Qt 4.4?)).
>
>
> Thanks,
> Dirk
-- 
 Torsten Rahn

 Tel.: 0 21 61 - 46 43 - 192

credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz