the "gamma" proposal - details that need working out

[Troy Unrau]

Okay folks,

I talked to many people at Akademy already about this idea, but Dirk
suggested that I send it to the mailing list to make it a little more
official and through official channels.  Discussion is still a valuable
thing on this particular issue, but based on the response from the packagers
and marketing teams here, this may be pretty much a done deal.  The details
of implementation need to be decided, and the release team needs to know
that we pretty much have a consensus from the marketing and packaging side
from those players that were present at Akademy.  Thus:

The proposal is to add another layer to the release stack called 'gamma' or
similar.  The release cycle up until Oct 23rd would remain unchanged, except
perhaps the RC sections might need to be renamed as gamma candidate, for
instance.

The goal of this layer is to permit the early adopters to use KDE 4 on Oct
23rd, while allowing those more conservative (who would normally wait for
4.0.1 or 4.0.2 before adopting 4.x) to get a 4.0.0 that they can actually
ship.

The original proposal is essentially to annouce Oct 23rd as gamma1 and Dec
11th or similar as gamma2 if desired.  Our date for 4.0.0 would then be
something like Jan 23rd or Feb 1st, which we really need to decide now so
that we can start booking hotels and conference rooms and so forth in
mountainview.

Here is some additional justification:

The main use of this extra time would be for bugfixing, translations, and
HCI relating tweaks. Additionally, the plasmoid community on
kde-apps.orgcan already have started to ramp up, so that when
4.0.0 is announced, and we've been promising a 'new desktop paradigm', well
there will be some actual applets that are using plasma to do new things
that have been developed in those three months.

The response from some of the people present representing the distros has
been positive, and those representing kubuntu, gentoo, suse, and mandriva I
have talked to at least, and there have been no real objections from them,
in fact they are ecstatic about having the extra time to work on packaging
between gamma and 4.0.0.  The general response from the members of KDE here
has been positive, while a few have been asking for clarification.

This is supported by the mountainview team (including myself, aseigo, sebas,
and a few others) with room for negotiation on any of the points of course.

The only real question (and this is not a marketing question) becomes when
to fork.  I would *personally* suggest you fork for 4.1 as soon as gamma 1
is live, treating it just like you would have treated 3.0.0 under the old
cycle.  However, if you want to encourage bug fixing and so forth, push it
back by a few weeks, or even to gamma2.  The point of gamma1 however is to
have every developer porting their stuff to kde 4 full time, and to let the
community have their stable platform release with which to start developing
the 4.x community, as well as finding all those corner case critical bugs
that we will have missed that they would surely find.  We will do the
marketing to ensure that the opensource community knows that they can use
the gamma while preparing a big splash for 4.0.0 three months later.

CC: kde-ev-marketing

-- 
Troy Unrau
Geophysics Student - University of Manitoba
KDE Gearhead, and Marketing Working Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/release-team/attachments/20070706/3d7b05d2/attachment.html