.. continuing my "I'm feeling ill, so am soaking in a bath" rambling thoughts:

Most of the plasmoids I personally wanted to work into 4.1 are getting punted to 4.2. WoC and a few other things sapped my time. Thankfully others have been working on plasmoids so we'll have some great new stuff there, I just wish I could've been able to play in Plasmoid land more (it strikes me as more fun than the infrastructure issues I deal with ;)

This is one aspect of the 6 month release cycle that I really don't like for Plasma: the punt rate increases. For some apps this is a complete non-issue, but for more complex bodies of code that are in high development states a 3 month feature window is just too tight to fit in more than a few things. The first month of a release cycle is usually not spent on new features in my experience, and the last couple of months in a 6 month cycle are spent stabilizing. What this means is that we spend half the year in non-feature development; over 3 years time a 9 month cycle (with 3 months of stabilization) gives me 20 months of feature dev while 6 months gives me 18 months. That sounds similar enough, but the windows are tiny in the 6 month cycle, meaning more punting which in turn means that many features will be delivered in 12 months time to the user rather than 9.

It's also pretty obvious to me that for other projects, a 4 month cycle is probably even more useful than a 6 month cycle. Web based CMS projects come to mind as a good example where 4 month cycles would be the "Goldilocks" (aka "just right!") cycle.

In fact, I suspect 4 months might the Golidlocks number for Plasma: 2-3 months of features, 1-2 months of stabilization and exercising those new features via plugins. Unfortunately, 6 is not very evenly divisible by 4 ;) so this wouldn't work for the current release cycle.

I know that 6 months is all the craze right now, mostly IMHO for the wrong reasons like "marketing" or "downstream synchronization", but also partly for the right reasons such as quick cycles with a known clock rate for better iterative development patterns. I really dislike the marketing and downstream control issues because the former is complete BS (I want to smack someone with a marketing textbook every time I hear them opine on how six month cycles are better for promo) and the latter is misplaced priorities (accommodating downstream by hobbling upstream is remarkably short sighted). Really it comes down to finding a way to satisfy different sets of priorities.

I spent some time today thinking about what it would mean if mainline Plasma development moved to a git repository outside of KDE's svn, syncing at "known good revision points" back to svn except during KDE feature freeze periods so that we can have development windows that make sense for Plasma without breaking KDE's release cycles. Downstream gets what they want (a tarball every 6 months) and Goldilocks gets what she wants. We could stabilize the Plasma code base wheneverit would make sense for Plasma and downstream can simply get whatever the last "good point" was when a KDE release happens. This effectively decouples release schedules from development schedules, not unlike what the Linux kernel has managed to do.

I don't think this will work if our merge cycle is longer than 6 months however: testers and new developers will likely work against what is in svn and I don't want to require people to have to use another repository just to get at Plasma. So the merge cycle would have to be shorter than 6 months to keep the illusion of "development done in svn".

Perhaps there's another answer, but something needs to shift because one development window size does not fit all. At the same time the road of "hundreds of individual repositories and tarballs released whenever they want" is not really an option either as that'd just be integration hell for everyone.

So there you go: ramblings with no real concrete answers .. yet. =)