Git policy for kde-baseapps?

[Frank Reininghaus]

Hi,

2012/9/20 Daniel Kreuter:
> On Tue, Sep 18, 2012 at 11:29 PM, David Faure 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)
>
> 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?

of course we should regularly merge the stable branch into master, and
if you read my proposal carefully, you'll see that I mentioned this
already. Without the merging, committing bug fixes to the stable
branch only would not make any sense at all.

Best regards,
Frank