[kde-ev-marketing] [Kde-hci] Suggested release schedule for KDE 4.0

[Aaron J. Seigo]

wow; lots of cross posting here; apologies to those on more than one of these 
lists.

On March 8, 2007, Olaf Schmidt wrote:

> * Qt 4.3 contains some layout system changes that are needed for usability
> improvements.

it seems to be shaping up that 4.3 will be the desired Qt version for 4.0. 
whether that is realistic probably depends on what the release schedule for 
4.3 will be and how irreplaceable features in 4.3 are for 4.0.

> * Qt Accessibility Framework: In middle-term perspective, all widgets in
> kde*libs and kdebase should provide the Qt Accessibility Framework with the
> necessary information to allow their use by users with disabilities (screen
> readers etc). The Qt Accessibility Framework changes in Qt 4.3 are done by
> Harald Fernengel and other Trolltech developers, so we depend on the Qt 4.3
> schedule. Harald, would it be possible for someone at Trolltech to complete
> a kde*libs/kdebase widget API review for accessibility needs within one
> month?

would potential changes result in API changes, e.g. such that they would be 
source or binary incompatible?

where can one find information on what sort of accessibility blockers need to 
be checked for in the API?

> * Consistent and complete keyboard navigation of all of KDE (we still need
> to evaluate whether this has any influence on the API)

this strikes me as something that can be added over time; e.g. doesn't prevent 
4.0 from shipping.

> * There might be a number of other (smaller) areas where API changes could
> be necessary for usability. The usability team does not consist of
> developers, so it will take some time and cooperation to complete this
> review.

or we simply  live with the idea of the usability people doing their best and 
get on with it. my guess is that several of the usability team members won't 
get their hands on a kde4 system until there are binary packages for their OS 
of choice available. we may have to suck it up and live with API changes that 
we can make during the kde4 cycle in this regard.

> > a feature freeze in early May,
>
> Does the feature freeze include changes as a result of usability reviews?

that would be very nice, yes.

> > and a release around October
>
> A quick stable release for kdelibs and kdebase/runtime seems to make sense,
> but an end-user release in October seems to be unrealistic. The user
> interface of important parts of KDE4 (e.g. Plasma, Nepomuk) does not exist
> yet and the usability team needs time to conduct a proper usability review
> of the new interfaces.

nepomuk will take time, yes. but it's something that can be added over the 
course of kde4.

plasma is in progress now and will be ready for 4.0, though possibly in 
similar shape to kdesktop and kicker in 2.0.

> KDE 4.0 will be reviewed as a Vista competitor,

that's a marketing issue, and the key is expectation management and clear 
communication about how the development process works.

> and it would make a 
> disastrous impression if core elements of the user interface are either not
> present yet or have an extremely bad usability because of a rushed
> schedule. It would also make a disastrous impression if important desktop
> applications (e.g. kdepim) are missing from the KDE 4.0 end user release.

it could be disastrous if we try and tell the world that 4.0 is The Release To 
End All Releases. it doesn't need to be disastrous if we communicate the 
difference and relationship between KDE4 and the 4.0 release milestone.

> Would it be possible to have a stable developer API release in October, but
> to release "KDE 4.0" as an end user desktop only after all important tasks
> are completed? (Is there any feedback from the marketing team on this?)

i don't think there is any point in doing this as it is, as you even note 
here, pretty much completely a communications issue. there will never be 
an "all important tasks completed" (knowing how that list grows in tandem 
with it shrinking =), and so we simply need to communicate clearly what 4.0 
is, what KDE4 is and how that all works together.

we can certainly do something like position 4.0 as the 
first "proof-of-concept" release for frameworks that will evolve over the 
KDE4 lifespan, primarily by finding their way into applications.

however, i think we need to be sure we're not steering the technical process 
of release management by marketing issues. rather, marketing needs to react 
to the technical process and realities.

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

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/release-team/attachments/20070308/2577854a/attachment-0001.pgp