In the recent Poll on KDEPims release schedule I wanted to answer, but realized the answer is not that simple; and KDE has been running in the same circle for too long to see that there have been developments out there which change the release stuff completely; in other words, time for my first BLog here 
This blog can be classified as a rant, but I have a little bit of a reservation about that. The simple thing is that I intend to tell nothing new here; there are millions of developers already using a development cycle which make the whole point of release schedule quite simple and obsolete.
My point? A release schedule is based on development cycle. KDE still has a (bluntly said) cycle of
- Refactor and wreak havoc -- all is broken and everyone knows.
- Week before feature freeze -- all is even more broken, but at least the features are in!
- Feature freeze, we fix what we broke before
- We release
The total time of this list takes anywhere between 4 to 8 months, and is global for the millions of lines of KDE code. There are those that like this way of working, but I sure as hell don't! I can't follow KDE on a stable box since I have to worry about loosing data all the time. What if this coding cycle could be brought back to, say, 2 weeks ? Sound stupid? Just make the tasks smaller. Even smaller then that. Still having a problem seeing how this could work, make the tasks even smaller (ad infinitum).
Keep Changes Small
What I have been experimenting with is a way of working that puts all your TODOs in an ordering of priority. If your TODO can't be done in a cycle (including debugging) of less then two weeks. Then you have to split the TODO into smaller pieces. This is explained better in an article here: Keep Changes Small.
If you grasp the concept, and actually try it, I'm pretty sure that all but the most-complete-rewrites can be finished, and debugged in under a month (taking hacker time in account here).
Fix your bugs fast
With shorter cycles people will suddenly start to be able to use your software fully again before its actually released. When a fellow KDE finds a bug or annoyance in your application, he can fix it or ask you to fix it directly; since the change that you are still hacking on that is very very small. In the end the feature freeze may still be needed; but it can probably be something like 3 weeks. Remember that the one finding most bugs is the developer himself; and if you have more then 2 weeks of bugfixing, then your methodology on keeping changes small is flawed
Prioritize your features and bugs
Its simple, really, if you do the most important features and TODOs first, then you won't have too much of a hassle releasing a month early since only the lowest priority TODOs and bugs are left.
I've been to a department that had all bugs in a system on those yellow sticky-notes. Each had a small description of the feature or bug and it was positioned on a (big) wall according to priority. The highest prio at the top, and similar priorities at the same level.
Every couple of days the priorities were re-done. Some things might have gained a lot of priority due to others depending on it. Some suddenly did not seem so important after all. Reshuffeling galore! Naturally the amount of reshuffeling got less and less after the project progressed.
In summery; with projects like KDEPim and KOffice having seperate release schedules we loose a lot of marketing value for those respective projects. All we need is developers developing in a lot smaller coding cycles which means that the software is stable at all times, just misses features that might impede it from an 1.0 release.
Stabler software means more debuggers and basically higher developer satisfaction.
More importantly, it means any project can release 'next month' if the release coordinator wants.
Do you want to know what I've been smoking (hint; I don't), or do you want to know more? Just hit reply.
Syndicate Blogs
This won't work.
It makes sense what you write. It would really be nice if we would keep changes small so that we would be able to release more often. The problem is that this won't work with KDE.
Your proposal requires that developers carefully organize their work. This might be possible if it is your job, but it won't work if it is voluntary work as it is for most KDE developers. It happens all the time that people implement something and go away before they finish it. This is their good right and part of the freedom of Free Software development. Sure it is not desirable that this happens, but it does happen and it's even not bad in many cases. A feature which is lying around half-finished for a while and then finished by somebody else is better than not having the feature at all, isn't it?
In addition to that I think your premise that everything is broken after a release is not true. This might be true for some parts of KDE and probably was the case for previous releases. But it doesn't happen anymore. The libraries don't change much and for example the kdepim module has been very stable throughout the development cycle since 3.2. So the main problem is not fixing heavily broken code, but to find a tradeoff between the additional work that a release means and the benefit it gives. There is a lot of coordination required between developers of different applications or modules, or with translators and packagers. Spending too much time on this because of very frequent releases is not a good idea. Having separate releases of individual modules mitigates this problem by the way, because it's much easier to coordinate work on one module than on all of KDE.
Well, and finally I don't buy your argument that by separate release schedules we lose marketing value. The contrary is the case, if stuff is released separately it is much easier to focus on the highlights of the different modules and applications. Who reads the full list of features of a KDE release? A lot of great work doesn't get the attention it deserves because it is lost under the overwhelming amount of changes contained in a general KDE release.
HEAD
You wrote:
I think your premise that everything is broken after a release is not true.
I believed you and recompiled to use HEAD (updated sunday evening).
Short version is that I'm surely going back to BRANCH since HEAD is seriously broken for all the major applications I tried; after 2 hours of playing with KDE I found over 30 bugs. KMail being responsible for about half of them.
Bug reports
Have you reported the bugs? I use KMail HEAD since at least half a year updating several times a week and hardly ever had any problems with it. When there were problems they were fixed within hours.
bugs
Bugs.kde.org was down at the time; I'll try to make some time for bug reporting later.
Notice, however, that there are 60 bugs open (not counting wishes) which I reported on bugzilla. I tend to find bugs that can't be closed within ours.
Re: won't work
Hi Cornelius,
there are two major parts in my story above; the small changes part and the organizing TODOs part.
The example of a feature being partly implemented by a passer-by uses both parts. Almost by definition the new feature is not high on the groups-priority list. Having others implement features that are not part of the feature plan does not really interfere with things.
The small changes argument basically said that the whole sourcetree should stay stable enough for the developer to oversee all possible disruptive things and be able to focus on the right sourcefile within minutes if a problem occurs. I'm pretty sure that if external patches are reviewed by the project owners that also is not really a problem.
In other words; having extra hands providing new features does not affect the proposal I wrote above.
If you had to release KOrganizer tomorrow; would you have to answer that its impossible because its too unstable? Then you would surely benefit from the way of working I described.
If on the other had you had to answer that you'd rather not because too many features you wanted in are not yet implemented, thats an altogether different (and better : ) story!
If you say that KDE does not suffer from major-brokenness after a release; I believe you. It used to be so, including the 3.0 release. But I have not been using HEAD since I lost too much data (and hair) back then...
On marketing value;
your answer implies that the target audience is like you; someone who looks at release notes based on postings on the dot, slashdot and other similar sites.
I'm pretty sure the majority of the market gets their KDE from distro's and friends. A new KDE release is like a new Windows release; you hear nobody talking about the Windows media player 10 (released less then a month ago) while everyone knows about the newest Windows (to be released in 2006) and what it probably will contain.
I dare to say that the upcoming KDEPim release is more important for managers then it is for end-users. How do you suppose managers get the news about the feature list of KDEPim? I'm guessing that they will read about it in the next KDE release, or the next SuSE/Mandrake release (whichever comes first).
Stability and Marketing Value
You are right that features implemented by passer-by don't need to affect your proposal if they are handled properly by the maintainers and other developers of the app, but they need some extra care. As I said before your proposal is nice, but I think it is too demanding to be implemented for KDE in a pure way.
Let me add some thoughts about two other points:
Stability
KOrganizer is stable enough for a release. We have fixed a lot of bugs, so in most areas it should now be more stable than the release before. On the other hand we introduced some new features and refactored some code. I have always tried to do this with small changes, but new code means new bugs. That's inevitable.
The only way to make code really stable is to give it lots of testing and try to change as few as possible. Even bug fixes potentially introduce new bugs, so it's better to leave small bugs alone, let the users get used to them and give computer magazines the chance to write "tips & trick" sections describing workarounds. Introducing new features will make code more unstable. There is no way around that.
Marketing Value
Managers don't read KDE release notes. In fact, nobody reads release notes. So how do managers get their information about KDE? They get it from the distributors. The distributors are those who do the marketing. They do it because they want to sell their product which includes KDE. This is something the KDE can't do.
But will distributors do marketing for KDE as a whole? No, they will focus on the stuff which is interesting for their customers. That's the reason why releasing modules separately could give us benefits. Upgrading whole of KDE is a big deal, but putting something like a new Kontact version on a distribution is much less hassle. So separate releases will get us more chances to get on distributions and this will result in more marketing done for KDE.
Re: Stability
You wrote:
The only way to make code really stable is to give it lots of testing ... Introducing new features will make code more unstable. There is no way around that.
Actually; there is.
Unit testing is exactly the technology that is invented to counter the problem you wrote above.
Fix a bug, run the unit tests (all 10-thousand of them) and you are sure that nothing else broke if they all pass.
I'm not saying you should now go create lots of unit tests; but the claim that bigger codebase means unfixable bugs and more regression bugs means you are missing a usefull technology.
Release schedules and development cycles
I had a look at the extreme/agile programming methodology (www.extremeprogramming.org) the other day. Now there it is said no code enters the CVS unless it passes the regression tests.
Question: Do we have regression tests in the code of KDE?
Sure, we have some... But *way* not enough.
Then:
The other a comment popped up at the PostgreSQL development list. The author stated that this was the only devel community he saw where the people want to keep up the feature freeze date to get their new features in, instead of releasing sooner to get the new features into the next release.
Now, this is justifiable by realizing that PostgreSQL, unlike the other devel teams, has:
1. Has a bunch of regression tests - should only one fail, the patch is not going to be applied
2. They have very few commiters, e.g. people with CVS accounts. These commiters first review every patch and commit only if the patch is OK with them.
What I see in KDE is the following:
1. there are almost no regression tests for the code that is under the GUI. Many times it is not even possible to write tests, because the code is tied too much to the GUI.
2. There are very many people with CVS accounts.
3. Nobody is writing design documents. I know that most projects are being developped as "I have an itch so I scratch it", but design documents are necessary for the followers of the enlightened - mind reading is *not* in the standard feature set of a software engineer.
Please, feel free to tell me your opinion.
Zoltan
tests
I agree, there aren't enough tests. I think that is why things can break and maybe nobody realizes it for a while. I have been fortunate not to experience data loss, but then again I don't run the unstable kmail. (Actually I just use mozilla still). But fear of the instability of the HEAD branch does prevent me from running the HEAD version of kdevelop. I need it to work.
As for lack of unit or regression tests, recently I was looking at the kmail code. I was thinking where are the tests? How can you have a 100,000 line application with virtually no tests? The only tests there are for the dcop interface, and the test program is about 15 lines and only tests two DCOP interfaces. (please correct me if I am wrong).
Re: Unit-tests
I don't talk to all KDE developers, but plenty of developers do create user tests. DFaure discussed a little xml-writing framework on the koffice-devel mailing list not too long ago and ended with a 'the code is committed, the unit-tests are created and I know it works. Now could someone else see how he can tie it to his application' ?
The point here is that writing unit tests makes writing that new library easy; it makes fixing that bug easier. Problem is that you have to actually learn how to do it. Writing unit-tests is not easy. There are many new designs to learn and some fears to overcome. And in the end its something that would be nice to have all developers do, really good actually.
In the end unit tests are not needed for the ideas I posted above; just the linear extension of it.
In fact; the writing of unit tests is a REPLACEMENT for writing design documentation. The API of any 'unit' is being tested, so the usage of that unit is described in code. This is a fine replacement for method-docs. Remember that any design docs tend to get out of sync with reality.