Okay folks, <br><br>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:
<br><br>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.
<br><br>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.
<br><br>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.<br><br>Here is some additional justification:<br><br>The main use of this extra time would be for bugfixing, translations, and HCI relating tweaks. Additionally, the plasmoid community on <a href="http://kde-apps.org">
kde-apps.org</a> can 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.<br><br>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.<br><br>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.
<br><br>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.<br><br>CC: kde-ev-marketing<br clear="all"><br>-- <br>Troy Unrau<br>Geophysics Student - University of Manitoba<br>KDE Gearhead, and Marketing Working Group<br>