On Saturday 23 July 2011 00:00:16 Nicolas Alvarez wrote:
> There is no active policy saying you're supposed to merge. Almost everybody 
> in KDE is still doing cherry-picks. KDevelop is the only KDE project I know 
> that consistently uses forward-merges from the stable branch to master.
> 
> ---
> 
> It *would* be good to switch to the new workflow of doing changes in the 
> lowest supported branch and up-merging, but it's not that easy. We need to:
> 
> - Figure out how to solve the scripty problem. scripty does its own 
> conflicting commits to .desktop files in both branches, and that won't 
> change[1]. We probably need a custom merge tool for .desktop-like files that 
> ignores translations.
> 
> - Check if there is any change in 4.7 that isn't in master, and if so, see 
> if that's intentional (4.7-specific hack, or the version bumps) or an 
> oversight (never cherry-picked into master).
> 
> - Do the initial merge from 4.7 to master, solving the conflicts. The more 
> they have diverged, the harder this is.
> 
> - Get *everyone* to start with the new workflow for that particular 
> repository (see below). Else, if some people keep cherry-picking while 
> others expect merging, the next one to try merging may get conflicts about 
> all the cherry-picks people did since the last merge, and a merge will make 
> commits appear duplicated in the log (as ossi pointed out to me).

During the stable branch freeze before a minor version release (such as currently before the 4.7 release), it isn't possible to commit bug fixes to stable first and then merge to master. Only master can be committed to, so presumably we'll have to continue to commit to master and cherry-pick later once the freeze ends. Either that or change the policy on freezes.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm