<div dir="ltr">Thanks for the reply. Not everyone agrees on a the name, but it sounds like Trunk Based Development was/is the model for the 5.x.  <div><br></div><div>To clarify, bug fixes (via phabricator) land in master (the trunk) and were cherry-picked back to the 4.x branch if applicable. I acknowledge that cherry picks are not always possible if things have diverged too far.</div><div><br></div><div>- Paul</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 28, 2017 at 9:58 PM, Michael Pyne <span dir="ltr"><<a href="mailto:mpyne@purinchu.net" target="_blank">mpyne@purinchu.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Feb 18, 2017 at 06:59:41PM -0500, Paul Hammant wrote:<br>
> In 2011, something bubbled to SlashDot from this community.<br>
><br>
>    <a href="https://tech.slashdot.org/story/11/08/07/2128222/KDE-Frameworks-50-In-Development" rel="noreferrer" target="_blank">https://tech.slashdot.org/<wbr>story/11/08/07/2128222/KDE-<wbr>Frameworks-50-In-Development</a><br>
><br>
>    TL;DR: what branching strategy to adopt for the KDE 5.x work, given<br>
> a wish to:<br>
>    1) stay abreast of 4.x fixes/releases,<br>
>     and 2) not make the mistakes of the 3.x to 4.x effort (whatever they were).<br>
><br>
> May I ask what actually happened re branching, merging, cherry picks<br>
> (back and forth) and all that, and what veterans think about it all<br>
> looking back?<br>
<br>
</span>For KDE Frameworks my impression is that the branching strategy in git<br>
itself turned out to be anticlimactic.<br>
<br>
Unlike the Linux kernel model (where a commit will filter through many<br>
different git repositories before eventually landing in Linus's<br>
"official" git repo) or the Github model (where a pull request is used<br>
to request review and then merge in commits from an external repo), we<br>
typically review the proposed commit's diff first (with Review Board,<br>
and now Phabricator) and once cleared to land, we integrate it directly<br>
into the appropriate git repos (we maintain a large number of separate<br>
rpoes).<br>
<br>
Since Frameworks is on a single-track, frequent-release model we don't<br>
routinely maintain separate stable and dev branches. So when reviewed<br>
commits are landed in Git, they go straight to master, and the eventual<br>
release is performed directly from master as well.<br>
<br>
This doesn't mean it's impossible to develop a long-running feature in a<br>
separate branch and merge it in later. But since it hasn't been<br>
necessary for development, the 'branching strategy' issue doesn't really<br>
come up here.<br>
<br>
Outside of KDE Frameworks (where we do typically maintain stable and<br>
development branches), both strategies are employed but generally we<br>
make any needed backports in the stable branch and then use a merge<br>
commit to forward-port to master.<br>
<br>
I think the discussion was good to have because it helped shine a light<br>
on some of the factors a git-using developer should consider and helped<br>
us to better use our source control tools.  But I don't think it really<br>
impacted that much for our development, at least in comparison to all of<br>
the many other best practices we need to be aware of.<br>
<br>
Regards,<br>
 - Michael Pyne<br>
</blockquote></div><br></div>