Git policy for kde-baseapps?

[David Faure]

On Wednesday 12 September 2012 13:22:48 Frank Reininghaus wrote:
> 1. Before a commit, which is not a merge, is pushed to either the
> stable branch or master, run 'git pull --rebase'. If the remote branch
> has moved on since the last pull, this prevents the creation of a
> superfluous and possibly confusing merge commit and keeps the output
> of qgit and gitk clean. BUT: If the commit to be pushed is a merge, do
> not run 'git pull --rebase' under any circumstances, see the
> discussion in [1] for the possibly disastrous consequences.
> 
> 2. Commit bug fixes, which are considered safe enough to be included
> in the next bug fix release (at the moment, this would be KDE 4.9.2),
> to the stable branch only. Someone will merge them to master from time
> to time using 'git merge'. I wouldn't do this after every single
> commit because this would needlessly pollute the history. Maybe it
> would make sense to merge the stable branch into master
> 
> * just before any large change in master, to prevent that a later
> merge of the stable branch would lead to conflicts,
> * just before any beta release is made from master, to make sure that
> all recent bug fixes are included in the beta packages, and
> * around the time of bug fix releases from the stable branch, to make
> sure that master users don't suffer from bugs which are fixed already
> in released stable packages.

I completely agree.

Incidentally, this is what we're doing in kdelibs, too.

(except that we run git merge more often, because new API is quickly needed in 
all branches, and to prevent too much merging work piling up due to the major 
differences between kdelibs-4.x and kdelibs-frameworks, but that is irrelevant 
in kde-baseapps)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5