Branching retrospective question re KDE frameworks 5.x work from 2011 onwards.

[Michael Pyne]

On Sat, Feb 18, 2017 at 06:59:41PM -0500, Paul Hammant wrote:
> In 2011, something bubbled to SlashDot from this community.
> 
>    https://tech.slashdot.org/story/11/08/07/2128222/KDE-Frameworks-50-In-Development
> 
>    TL;DR: what branching strategy to adopt for the KDE 5.x work, given
> a wish to:
>    1) stay abreast of 4.x fixes/releases,
>     and 2) not make the mistakes of the 3.x to 4.x effort (whatever they were).
> 
> May I ask what actually happened re branching, merging, cherry picks
> (back and forth) and all that, and what veterans think about it all
> looking back?

For KDE Frameworks my impression is that the branching strategy in git
itself turned out to be anticlimactic.

Unlike the Linux kernel model (where a commit will filter through many
different git repositories before eventually landing in Linus's
"official" git repo) or the Github model (where a pull request is used
to request review and then merge in commits from an external repo), we
typically review the proposed commit's diff first (with Review Board,
and now Phabricator) and once cleared to land, we integrate it directly
into the appropriate git repos (we maintain a large number of separate
rpoes).

Since Frameworks is on a single-track, frequent-release model we don't
routinely maintain separate stable and dev branches. So when reviewed
commits are landed in Git, they go straight to master, and the eventual
release is performed directly from master as well.

This doesn't mean it's impossible to develop a long-running feature in a
separate branch and merge it in later. But since it hasn't been
necessary for development, the 'branching strategy' issue doesn't really
come up here.

Outside of KDE Frameworks (where we do typically maintain stable and
development branches), both strategies are employed but generally we
make any needed backports in the stable branch and then use a merge
commit to forward-port to master.

I think the discussion was good to have because it helped shine a light
on some of the factors a git-using developer should consider and helped
us to better use our source control tools.  But I don't think it really
impacted that much for our development, at least in comparison to all of
the many other best practices we need to be aware of.

Regards,
 - Michael Pyne