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

[Paul Hammant]

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.

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.

- Paul

On Tue, Feb 28, 2017 at 9:58 PM, Michael Pyne <mpyne at purinchu.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20170228/514d3a04/attachment.htm>