Fixes in Git (first in stable, then merge to master)

[Ben Cooksley]

On Sat, Jul 23, 2011 at 6:52 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> On Saturday 23 July 2011 01:42:16 David Jarvie wrote:
>> 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.
> Seriously: is this technically enforced or is it believed that developers know about it?

Technically enforced: No

All developers should know about it, as they were sent a set of
instructions from sysadmin when they gained access to KDE SCM servers.
A copy of it can be found at
http://websvn.kde.org/trunk/kde-common/svn/svn_git_instructions.txt?view=markup

It contains a link to
http://techbase.kde.org/Policies/SVN_Commit_Policy (which also applies
to git i'll add)
That has a section "Respect commit policies set by the Release Plans".

> Personally I have no idea when the stable branch will be tagged or released. I commit to the
> stable branch in order to fix a bug and in the hope that it will some day end on the users'
> systems. But I do not care when this will happen and I never was blocked because of some
> tagging freeze.
>

We have Release Plans published on the wiki, and available as an ics
file on www.kde.org which matches that for use in Kontact, etc.

> So unless this is not technically enforced, the policy are nice words which I beleive nobody
> cares about.
>
> Cheers
> Martin

Regards,
Ben