Git policy for kde-baseapps?

[Daniel Kreuter]

On Tue, Sep 18, 2012 at 11:29 PM, David Faure <faure at kde.org> wrote:
> 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
>

Hi,

overall a good idea, but I see one disadvantage of proposal 2: When
committing bug fixes only to the latest stable branch, you gain the
disadvantage that it could happen that this fix won't be in the next
major version (f.e. KDE 4.10) and you have to pull it there later or
try to fix it again because you (or someone else) forgot that this fix
is already in the KDE 4.9 branch. Maybe we can regularly merge the
latest stable branch into the master or next version branch, f.e. once
a week?

So long

Daniel