Table Of Contents
|1.||11 May 2003 - 23 May 2003||(49 posts)||KDE 3.2 release cycle|
Sorry about the delay in getting this one made - I was waylaid by a personal crisis. Not sure if it's over yet, but I think I can squeak this one out. The good news is that the 3.2 thread finally calmed down enough that I can report on it. Man, do those crazy developers know how to talk! :-) There's only that one entry this week, but it's enough for three regular ones!
I also have some mods that need to be made to last weeks, I'll try to get those done soon.
On with the show, I suppose.
Mailing List Stats For This Week
We looked at 653 posts in 2838K.
There were 210 different contributors. 96 posted more than once. 83 posted last week too.
The top posters of the week were:
1. KDE 3.2 release cycle
11 May 2003 - 23 May 2003 (49 posts) Archive Link: "KDE 3.2 release cycle"
People: Dan Duley, Stephan Binner, Daniel Stone, Reinhold Kainhofer, Neil Stevens, Stephan Kulow, Ingo Klöocker, Aaron Seigo, Datschge, Navindra Umanee, Torsten Rahn, Ingo Klöcker
Mosfet, aka Dan Duley, who appears to be back from the dead now, had this to say, starting off a flood of posts that stretched over pretty close to a complete two weeks:
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.
Stephan Kulow retorted that there are about 2300 confirmed bugs, and a few more of those should be closed first. To which Stephan Binner replied that the actual bug count that affects release is much smaller, and made the point that nothing prevented the 3.1.x release with a considerable number of grave bugs. He also said, "Either switch to a time- based or feature based release system now." . To which Daniel Stone, in his own unique and inimitable style, replied:
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".
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 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.
: 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.
And Stephan Binner replied again:
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.
To which Daniel Stone replied yet again:
"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.
But with a differing view, we have Reinhold Kainhofer:
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.
Torsten Rahn agreed and made the point that any release date planned past six months causes people to rip out large chunks of the code and plan over- optimistically how long it will take to put them back.
Mosfet, never one to not have the last word (or two, or three), responded:
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 >;-)
That last sentence, of course, is one of the few things in the kde-developer list that won't cause a firestorm of controversy requiring UN inspectors.
Meanwhile, back in the batcave (elsewhere in the thread for those who are 60s American pulp culture deprived - you lucky bums), Neil Steven made this point:
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.
On the same bat-channel, at another bat-time (sorry, I can't seem to think of any other references), Ingo Klöcker made another good point:
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.
Rainer Endres made the point that a lot of cool ideas will be coming out of Nove Hrady, and allowances should be made in the release schedule for those ideas. Aaron Seigo agreed conditionally, with the caveat that there shouldn't be a huge amount of time between Nove Hrady and the release, essentially just put in what can be done in <3mo. Stephan Kulow replied that he wants to wait for Nove Hrady because he's not even sure if he'll want to scrap 3.2 and go right to 4.0 (!?!).
And, (whew), Daniel Moltenki made the point that Kontact is nowhere near ready for a release. Coming out of this thread was a suggestion for snapshots. It was pointed out that they already exist. Aaron Seigo responded to that:
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.
(ed. [Russell Miller] I don't have a firstborn, so that's not an issue for me. )
Datschge said, " I think what Mosfet wants to see is more public activity reflecting all the new improvements in the public. To keep it short: in my opinion this is not something the developers should care about but promoters. " To which the everpresent and omniscient Navindra Umanee responded:
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 (http://dot.kde.org/addPostingForm) ).
(ed. [Russell Miller] Whew am I glad that thread's over. You guys made me actually work! )
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.