[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Branching retrospective question re KDE frameworks 5.x work from 2011 onwards.
From: Paul Hammant <paul () hammant ! org>
Date: 2017-03-01 4:32:02
Message-ID: CA+298UiAmhc+M8SKUKU=Tg8HXFvrvP5=5X9mofuq2QSDcu2OfQ () mail ! gmail ! com
[Download RAW message or body]
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@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
>
[Attachment #3 (text/html)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic