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 <[email protected]>
