Okay, I know everyone is talking about this, but I also think the KDE3.2 release date needs to be moved up. I've been using CVS HEAD and at least for what I am using it is quite stable and has more than enough new functionality to justify a new release. I know there is a ton of things people want to do but 3.2 is just a minor point release, not KDE4.0. I'm rather impressed with what has been done already, esp in regards to Konqueror and Kontact/KMail.

The reasoning for this is while we all know what is going on and how much things are improving users generally don't. So we look like a slow turtle compared to other projects that do, (unofficial), releases with long changelogs every couple months. Development has been impressive, we should show it off either with unofficial releases or by doing stable releases more often. We are not very far from something that could be a stable release, but even doing an unofficial release would be an improvement from the current process, which is a long wait between KDE3.1 and 3.2. Just expecting people to use CVS is not enough, they want snapshots with changelogs, screenshots, and other goodies. Even if the project just grabbed a CVS snapshot that is determined to be relatively stable and released it with a changelog and documentation, that would be an improvement.

I'd think the issues that would need to be cleared up first would be the contact management and groupware stuff, KHTML, and all the desktop file changes. After that it would be good for the project to do a unofficial development release at the minimum.

I'm sorry, but this is something I cannot accept. If we start shipping releases based on time/features, then we're going to end up with something buggy. I'm sure most users would rather have something very nice that works, rather than something that's very very shiny and jam-packed full of eyecandy, that segfaults whenever you click on "Lock Desktop"[1].

We have a responsibility to our users. There's a place for "get all the features and eye candy you want, but this edge bleeds". It's called CVS. We already have excellent infrastructure[2] for this, so I don't see the need to turn releases into a second CVS stream.

To me, when I see kdelibs-x.x.x.tar.bz2, that says to me, "Ah, a release. Tested. Stable. Works". It doesn't convey to me, "Ah. Shiny. Immature. I gotta get me some of that". If we start releasing based on time/features, not stability, I can guarantee you that we will start losing users. The people who are that hellbent on shiny new stuff will grab CVS anyway. Others will just live with it.

...

[1]: kdesktop_lock segfaults when you click on Lock Desktop, but my checkout is old. Still, it's a very good example of why shipping based on time/features is utterly bogus.

You seem to wrongly assume that "time-based" means the actual release date and therefore no more beta/RC releases if there are too many errors? Then you're wrong. I mean the date of the feature freeze: Add only the features/programs which are ready at a given feature freeze date (that's like the last releases were managed). "Feature based" in opposite would mean to define the features that have to be in and then delay (endlessly) the freeze until all are there.

"Time-based" still isn't stability-based. I'm all for letting the release date slip if it means we get a better-rounded release. I personally think it should be up to the RM's discretion. If the RM does a bad job, the developers will complain, and either he will learn, or there will be a new RM - it doesn't get much more simple than that.

Obviously the lack of any publicly-raised objections indicates some level of developer faith in the RM; are there any objections anyone has now in the RM's ability that weren't raised at the time? If there are, I'd like to know, as the RM is an absolutely crucial position for any project.

I have to agree here. As long as there is no feature plan freeze and feature freeze announced, people will happily add new features and delay fixing bugs until they absolutely have to. In kpilot, I have so many ideas for new cute features, and I like working on them much more than fixing our bugs (kpilot is rather high in the bug-count list, but many bugs are old or hard to impossible to reproduce etc). Especially since I know the next release will only be in almost a year or so, I don't have so much incentive to fix bugs right now.

I guess I'm not the only one thinking this way...

So, I'm all for announcing a feature plan freeze relatively soon, so that people really start planning which needs to get into 3.2.

Well, as I said before I don't think we necessarily have to push up the stable releases although CVS has been very stable for me so far. As was noted many bugs listed on bugs.kde.org aren't crashes but other behavior that isn't optimal.

I do understand that there is a lot of cool things people want to do for KDE3.2, especially in regards to kde-pim, and I'm all for that. What I think now would be good is for us to occasionally release development snapshots with descriptive changelogs, screenshots, etc... to show off what has been accomplished already. This is very hard for someone to just go ahead and do because the changelog - it would require developers to sit down and take a our to list all the new stuff they implemented. It shouldn't just be "Merged Safari changes to 05/12/2003 snapshot", or something like that. It should actually list what that would of improved and only developers really know that.

The point of all this being to give the users an idea of all the progress that has been made up until that point. Not that they would want to actually use the snapshot, or that it would have all the features or even most of the features we want in a final release. It's more to keep users informed. As I said in my previous post KDE development seems slow to many users because they don't get much information all packaged up in one place during the development cycle. Weekly updates on what is going on in CVS is fine but it can't beat impressive changelogs listing everything from KDE3.x and CVS HEAD ;-) People forget what happened last week - the changes need to be listed in one place occasionally.

And of course all this is my opinion >;-)

So, why will delaying get more bugs fixed? Do you think that developers want to fix them, but just don't have time? Do you think that developers haven't wanted to, but will to get the release out?

There's a big difference here. If developers don't want to fix bugs, then delaying won't get the bugs fixed. The developers will just keep adding features, making stability gradually worse, for that's what separate releases are for. Or if a feature freeze is imposed, then development will just move off of HEAD. You can't force volunteers to do what they don't want to do.

I think some sort of compromise is needed. Go with stability-based releases, but with a default time if the stability goal isn't reached by then.

I haven't said something else. I just said that I won't decide on the default time before Nove Hrady happened. And very likely we'll do a preview before Nove Hrady started.

It's really not that easy. If people try out whatever version we release then they expect that those releases don't trash their data (even if we mark the releases as alpha releases). With KMail we currently can't guarantee that the new cached IMAP implementation which surely a lot of people will want to give a try will kill all your mail. In fact, this already happened to one or two people who are using the cvs version. Therefore KMail is currently not in a releasable state (not even as alpha release because many normal users don't grok what alpha release means). Not that you get me wrong, in general the current development version is very stable. But it's just not ready for the general public.

it's great that they are available and that their creation is automated, but there are two challenges with ftp.kde.org/pub/kde/snapshots as i see it:

o there is no coordination as to when they are to be tagged. when a person downloads those tarballs, they get recent CVS: broken or not. this makes them worthless as preview releases, which should offer at least a modicum of stability. they wouldn't require the QA / testing that an actual release or even an alpha release gets, but they should be tagged around times when CVS "feels" healthy (fewer crashes, motr new complete features, etc).

o they aren't publicized. Mosfet's original concern, as i read it, was that if the "KDE fan" part of our user base was left without visible signs of life and/or something new to play with every few months while we extend a release cycle, they won't be very happy and may decide that KDE development is slowing up or even stopping. this would be a job for kde-promo.

the build script in there is ok, but something like konstruct would probably be more useful, as it takes care of the downloading as well as the building and installing... and since these are "might kill your firstborn if you use it" type releases, it should be installed in the home directory.

obviously, this is all a moot point if we don't have longer release schedules.

This is the best way to see your work *Not Be Promoted*.

So, I'll take this chance and tell everyone:

If you just implemented this really cool new feature in KDE, or you *know* a really cool new feature has been implemented in KDE, and you want people to know about it, or you're sick of the perception that KDE is not moving:

Please take 5 minutes of your time to tell us about it (http://dot.kde.org/addPostingForm ).