managing time line mismatches

In a blog entry last week I talked about three challenges that arise as the number of individual groups participating in KDE has grown: time line mismatches, differentiation pressures and confidentiality requirements. I also said I'd write something about possible ways to address each of these issues to smooth out some of the wrinkles they can cause. Let's start with time line mismatches.

In describing this issue, I wrote:

"When a large number of diverse interests come together, each with their own release requirements, market goals and deadlines it becomes inevitable that time lines will not match up across every single participant in the community.

While perfect cadence would be lovely, reality is that different kinds of software and different business interests will have different requirements when it comes to time lines."

A concrete example might be a company working that has a private development contract with a third party that includes working on an upstream piece of KDE. This is actually fairly common and can be seen in Akonadi, Kontact, KOffice and Plasma to name just a few. This may sound like a great thing, but those contracts often come with delivery schedules attached to them. Those schedules may not coincide with KDE's upstream schedules, and diverting KDE's schedules just because company Foo signs a contract this year with government or company Bar doesn't make sense in the least. So what can we do?

Here are some of my thoughts on that question, some (all? :) of which are probably somewhat obvious. As usual, I don't have the definitive set of answers: there are certainly other approaches out there. Please share them with us if you know of some. :)

Communicate

This is the most basic part of any answer: if the larger community around the software knows when your schedules come to a close or when certain milestones must be met then the odds of the rest of the community working to accommodate, or at least not get in the way of, your schedule increases dramatically.

Due to confidentiality requirements, it may not always be possible to be overly detailed about some aspects of the schedule, but almost always it is possible to give at least a general outline of scheduling requirements.

The simple act of communicating has helped us in Plasma a few times, and the lack of such communication has also caused some real problems for us as well. It's amazing how important and useful just one small email can be.

Feature Branches

Sometimes it is necessary to work on features outside of the time windows alloted by the upstream project in which new features can be merged. Feature branches are a great way to work around this. By keeping such development away from the main development area it is often possible to keep feature development going without stepping on the toes of the upstream's schedule.

An important point is to commit to merging that feature branch as soon as it makes sense to do so. Also, as bugs elsewhere are often uncovered while adding new features, make sure that fixes to existing code are either made in mainline and merged back into the feature branch or that the fixes are merged immediately into mainline from the feature branch. This allows mainline to continue to benefit from your efforts and not to diverge too far from your branch when it comes to code not directly related to the new feature set.

Such a "diverge, but as little as possible" approach can accommodate multiple feature set efforts in parallel quite efficiently. Paired with a VCS like git that makes merging easier (than, say, svn *sigh*) features can develop and land fairly independently.

The downside to the feature branch approach is that it gets less testing and can end up conflicting with the design of other features. The more divergent and numerous feature branches get the harder it can be to track each of them and ensure each gets merged in a reliable manner.

In Plasma, when we have feature branches we track their progress fairly closely and try to merge them into mainline as early in the development cycle as possible. This, of course, means knowing when that feature will land, but we rarely have features that take more than two full cycles to implement or that can't be broken up along those lines. We have even taken to doing "merge fests" at our developer sprints, as doing big feature merges in person with a group can sometimes be easier and more efficient.

This helps us keep Plasma from becoming overly "branchy" while respecting the time lines of each developer without keeping the release cycle meaningful in terms of being when we land and integtrate features, test them and get user feedback on them.

Stabilization Branches

Stabilization branches represent the opposite case to feature branches. This happens when someone needs to ship a product around a given piece (or pieces) of KDE while the upstream project is still working on new features or features that are outside the contracted scope. The idea behind such branches is work on stabilization, optimization, etc. of the code in order to make the requirements set out by the schedule.

When the product to be shipped is based on a recent release of KDE this can be very easy: work in the stable branch (e.g. /branches/KDE/4.x/foo/) and forward port fixes into mainline. When the product to be shipped relies on work in mainline or includes features in a feature branch that hasn't yet been merged into mainline, then a new branch may be needed. Remember to merge changes back into mainline as appropriate as you go, however, so that everyone can benefit.

Some fixes aren't merge-able: they might be on a feature not in mainline yet or be an ugly short term work-around for something that is fixed in mainline in a way that can't be in the branch. Those are the exceptions, however, and should remain that way.

The KDE PIM folk have an "enterprise" branch and they regularly merge large sets of patches from that branch into the main line branch. This has proved pretty effective, at least by my observations, in the time they've been doing so. They tend to them in batches, and that seems to be an efficiency measure: they can sift through a number of changes all at once after they've been proven in the stabilization branch and discard the inappropriate ones leaving a batch of commits to process all at once.

I wonder how much of this is done by hand by them (KDE PIM people, any ideas?), and have often craved some nice tools for managing such things. Fiddling with the vcs directly is OK, but I can imagine much better workflows which could be aided with some purpose built tools.

Prevention

Perhaps the most obvious answer to conflicting time lines is to avoid them whenever possible. With one group I worked with this year, we actually pointed out the upstream schedule and the client adjusted their deployment schedule to fit that. This obviously isn't always possible, but it is possible more often than one might at first expect. Upstream doesn't always need to be the point of flexibility, and if the client group has flexibility in their schedule that can often be a much more natural and easy place to flex.

Finis; Now your thoughts?

What methods have you employed to deal with time line conflicts? How well did they work? What are the limitations of them?

The next entry on this topic (in a few days time) will be on the issue of differentiation pressures. It's tricker than time line issues in my experience, so I'm looking forward to writing about it. :)