KDE git workflow

[Cornelius Schumacher]

On Thursday 09 June 2011 David Jarvie wrote:
> 
> One side effect of using integration branches in what used to be
> kdelibs/kdepimlibs/kdebase is that new features aren't likely to be widely
> tested until later in the development cycle than previously. While they
> are in integration branches, only people who are particularly interested
> in those areas are likely to use them, and it's only once they eventually
> reach master that they will be widely used by developers. In one way,
> that's a good thing, since there should be less bugs encountered by those
> not directly involved. But the overall effect could be to slow down bug
> fixing of new features.

This is a valid concern and we actually discussed it at the sprint. One of the 
goals of integration branches indeed is to make new features available to a 
wider audience than just the developers who work on the features.

To make this happen we need to make these branches visible, communicate what's 
going on in them, and advertise them to other developers and adventurous 
users. One project which does that successfully is the Kernel, so maybe we 
could do it in a similar way. We might have a "Aaron's branch" of Plasma with 
the latest Plasma features, or a "KDAB branch" of KDE PIM, which integrates 
the latest KDE PIM enterprise features, etc.

We have some flexibility here, and it probably will take us a bit of time to 
find the right balance, but hopefully the model proves to be strong enough to 
accommodate our needs for stability as well as rapid bug fixing of new code.

-- 
Cornelius Schumacher <schumacher at kde.org>