On Wed, June 8, 2011 6:03 pm, Cornelius Schumacher wrote: > As you already know, we have discussed the git workflow for KDE at the > Platform 11 sprint, and have come up with a recommendation. Please find > the > full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow > > The core ideas are that: > * master is always kept in a stable state that is ready to be used for > starting a release > * development is happening in feature branches > * for larger projects integration branches will be used for further > stabilization and wider testing > * changes going into master are going through a review process > * releases are coming from release branches > > Please read the full text before commenting to get all details. > > This workflow will be adopted by some core modules, and is recommended for > all > KDE modules. It's flexible enough to be used by modules of different sizes > and different requirements in terms of stability, so we hope it to be a > reasonable > fit for as many people as possible. Obviously we'll have to see how well > it works and adapt it, if necessary, but it should be a good start.
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. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
