kde-runtime module master and KDE/4.9 branches

[Laszlo Papp]

> Problem with this approach is the code you backport is usually a lot less
> tested as you made all your developments on master. In the svn days I even
> remember people telling me they were blind-backporting to stable because it
> was "too much work to test the backported code".

One could say the opposite as well for the upcoming versions from
master, so it depends on the point of view what you focus for. :-)

> It also makes it difficult to know if a fix has already been backported because
> it has different commit-ids depending on the branch it has been committed to.

The commit id is not the only one to match. You can also match commits this way:

" Backport bugfixes

If you commit bugfixes, consider porting the fixes to other branches.
Use the same comment for both the original fix and the backport, that
way it is easy to see which fixes have been backported already. "

from: http://techbase.kde.org/Policies/SVN_Commit_Policy

So as for cherry-pick, this would be a clear identifier as far as I can tell.

The problem I see with that approach is if a bugfix is forgotten to be
cherry-picked, it may be hard later to recognize which commits need to
be cherry-picked from master if someone would like to volunteer with
that if there are no clear identifiers for that in the commit message.
For instance a bugfix which is not made for a bugzilla entry.

> I lke this rule from gitworklows (man gitworklows or [1]):
>
> "Always commit your fixes to the oldest supported branch that require them.
> Then (periodically) merge the integration branches upwards into each other."

Okay for me if it is demanded by our policy it has to happen, and
someone volunteers for making sure it does happen. Otherwise, the
upcoming releases from master may lack the bugfixes potentially.

> If we have an agreement to use fix-stable-and-merge, I'd be happy to get
> started on writing a script to check for missing merges.

Great. :-)

> Actually something
> like that:
>
> git log --pretty="%an <%ae>" origin/master..origin/KDE/4.9 \
>    | grep -v scripty at kde.org  | sort | uniq
>
> Could be a good start. It lists all authors of commits which are in KDE/4.9
> but not in master (and, there is my name in there :/). Of course it cannot
> tell if a commit is actually a cherry-picked version of another commit in
> master, so there are a few false positives.

Why not? I think even if the commit message is poor like "build fix"
and it is the same for more commits, you still have the chance to make
sure they are the same in master and the given release branch
according to further information like the diff for instance. In case
of no ambiguous commit messages, it is less problematic.

Laszlo