re: re: ramblings on 6 month cycles and Plasma

Toma took the time to reply to my blog entry on the six month cycle. He raised some ambiguities that I could probably clarify on a bit.

"First point is the very complex reasoning of the available time to do new features with a six months release cycle, which according to Aarons calculation means that half of the year we are in non-feature development. I don't understand that. "

As Toma calculates, 4 out of 6 months are spend in feature development. At least that's what the schedule says. A common pitfall in management (of any sort) is to keep your eyes on what is written on paper (the theory) and not glance up to examine what's really going on in reality. Reality is that right after a release I spend time doing the following three things:

• Catching my breath a bit (let's call that a day or three, so not significant)


• Responding to bug and wishlist reports; these tend to pick up right after a release and I like to spend the start of each cycle working on the x.1 release that is going to come out soon after the x.0 release. This is usually a significant time sink in the first couple weeks.


• Surveying the landscape, revisiting the feature plan and figuring out exactly what will be done in this next cycle. This is impacted by the results of the last cycle as well as the ever evolving needs and desires for the product. This too takes time and prevents immediately diving in to new feature development

It is not unusual, in my experience, for working on bugs, wishlists and drafting the next cycle's hit list (which hopefully is based partly on an already laid out set of goals, but must also include what got punted as well as shifted priorities) to take a few weeks of time. Therefore, I don't expect a ton of new feature development in the first month of a cycle. This is born out by what happened this first cycle around, and matches with my experience from past projects as well.

That means that effectively we have 3 months of feature development. Sure, what's written down in the theory (the schedule) says 4 months ... but I live in reality, and therefore management of my resources should too.

"I hear you scream that svn branches suck."

No arguments from me there ;)

"moving it to git repositories will give you a lot more overhead and merging that all back at intervals to KDE's svn will frustrate you as well."

Not if we don't do any development in KDE's svn and simply use it as a release dump. There are decent scripts out there to replay git commits into, e.g. svn. This would be a lot easier if KDE were using git as well, but really .. I don't want to start the vcs discussion here. This is about release schedules, the tools that we use making that harder or easier to cope with is another discussion altogether.

"With git you usually merge a completed feature, making the diff too large for people to check on the mailinglists. At least I prefer ten smaller commits to review than one big one."

We use review board for this and it works just fine, actually, especially for larger patches. We can always replay the git commits one by one if we wish, but really that too is a detail. With development happening in a separate repository, we can do all our small commits in usual chunks there and then merge back to the release branch however we see fit.

This is where I get really uncomfortable, though: to solve the issue with an inappropriately sized cycle, I end up moving the development away from the KDE infrastructure which is totally counter productive from the perspective of shared development. This particularly hits us when it comes to internationalization (i18n), but more on that in a minute.

That alone makes me hesitate. I feel like I'm between a rock and a hard place on this one. The rock is a poor choice of release cycle for my work in plasma, and the hard place is our current vcs tool being too poor at merging branches to even consider using it as a solution to the release cycle problem.

Ugh.

"After the period merge back, people using KDE's svn will make build fixes, etc. That will need to sync back to the git repository."

The number of such commits would be trivial and easily tracked even manually. Still not wonderful, but I'd rather optimize for mainline development speed than occasional build and bug fixes.

Note that I already read every commit to the plasma codebases (libplasma, plasma, krunner, extragear, ..) so this is already factored into my work life.

It actually isn't the build fixes, however, that will be a paint. It's the translations: those are scripted to work against our shared svn repository and those would need to get sync'd back and forth regularly. Supporting i18n scares me in this scenario.

"I'm sorry, but if you want more hacking time, this is not the way to go in my opinion."

Merging from a mainline devel git repository to an virtual read-only release branch in one big go is 15 minutes work. Watching for code commits from svn and syncing those back isn't a big issue either, and also mostly able to be automated.

So I think you're vastly overstating the overhead this would incur on my part. Unfortunately, it would really hinder i18n and raise the bar for new people to get involved (another repo you have to know about and another vcs that you have to know how to use).

It's really interesting how this choice in cycles results in degrading one or more of the following: existing development efforts, new comer involvement and i18n. Yes, I know it all looks good in theory ... but history is littered with failures due to deciding based on theory instead of what the theory actually means in practice.

I also disagree with the general remark that a 'six month cycle' does not work for you in this project. How on earth is it possible to judge that, when the very first cycle is not even completed.

Well, this isn't exactly the first project I've ever worked on. =) As for plasma itself, I've seen what this cycle has done and have already spent some time mapping out the next one; I fully expect the next cycle to be a repeat in many ways of this one. So, lots of good development, but lots of punting combined with sprinting to get features in under the wire. This is really the funny thing about the choice of "6 months": it's short enough that timing matters a lot, but not short enough to be suited for fast iterations in development.

It's a lot like trying to avoid stepping on the cracks in a sidewalk where the slabs aren't quite a multiple of your natural stride: you can do it but you end up losing your rhythm and looking like a bit of a goofball in the process.

"I always learned from my mother (hi mam!) that I need to give it a try for a couple of times before deciding it does not work."

That's good advice from your mother. I'm sure she'd also tell you to learn from the mistakes and successes of others, to not repeat errors you've made in the past and to repeat your successes whenever possible. It's not like creation cycles are a new science.

It may be the first time KDE's tried to stick consistently to such a short cycle period, but it's not my first time around.

"The schedule is not set in stone and if you have reasons to change things, mail the release-team."

If I had an idea of what would both work globally and also wouldn't result in me sinking days of my time into a discussion and decisions process I would. Right now, I'm not sure what the best solution is for all of KDE. I honestly haven't gotten to that point in thinking about it. I just know that for the project I'm most deeply involved in, it sucks. That doesn't mean it isn't perfect for other aspects of the project; as I said in my original blog this is a "one size does not fit all" sort of issue, and I suspect 6 months might work just fine for kdelibs.

If you're wondering why previous release cycles didn't cause such angst, it's because if a cycle is longer than you need or short enough to match natural short-term iterations it's not a big deal. KDE always tended to have longer-than-strictly-needed cycles which made them fit really well a broad cross section of the project and, I would argue, thereby actually increasing the development pace.

It's really hard to argue with the pace of KDE3 development.

So, I've no concrete solutions for the problems mentioned in Aarons blog,

Damn! And here I was hoping someone smarter than me would come up with the brilliant and obvious solution ;)

I can understand that a new project requires a lot of setup for the infratructure, but when that's done things will get easier.

This is the "it will eventually be done" theory. That theory works really well for projects which have a fairly limited scope (so a limited amount of internal pressure) that gets applied in an environment that is mostly static (so little to no external pressure). Unfortunately, Plasma has both huge ambitions (so lots of internal pressure to keep moving) and competes in what is right now one of the more competitive and evolving areas (primary user interfaces and the bling that makes them sing) which means lots of external pressure to keep moving.

I'd be very surprised if core Plasma development settles down within two years time. While we may not be mucking with existing code (source and binary compat being what it is), there is a lot left to be added.

Anyways, thanks, Toma, for taking the time for a well reasoned reply. Hopefully the above gives you a bit clearer idea of what thoughts are rattling around my wee little head.