[Development] [HEADS-UP] Updates to branching scheme

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Fri Nov 25 17:09:30 CET 2016


Il 25/11/2016 13:40, Oswald Buddenhagen ha scritto:
> - 5.6 is *NOT* going to be forward-merged any more, *ever* (also not to
>   merge tags)
> - you may integrate only changes which have been already integrated into
>   a stable mainline

Sorry, but need to raise an objection against this strategy, or at least
ask for many more clarifications about this process.

To me this looks like asking all contributors to at least double the
effort necessary to fix bugs that are (also) present in 5.6: patch 5.x,
get it merged, cherry-pick to 5.6, get it merged there.

On average, the cherry-pick to 5.6 will mean rewrite the patch, because:

1) The whole motivation for stop doing merges from 5.6 forward is the
high number of conflicts between the branches. Therefore, I can assume
that conflicts will be also be hit when cherry-picking back.

2) I am happily going to -1 any patch aimed at 5.7+ which does not use
C++11 features if it can (and should, according to the coding policy).
Any such patch will require modifications. We even kept our code base in
a certain "shape" (still using Q_FOO macros for C++11 features, etc.)
because we wanted to minimize the chance of conflicts when merging from
5.6; now that motivation is not there any more, right?


So, while on one hand this new branching scheme distributes the burden
from the current merge masters onto the bigger community, in practice
I'm very afraid (read: almost certain) that this will mean that very few
people will be willing to do the extra work, hence leaving 5.6 unpatched
for ordinary, non-critical bug fixes. This makes using a LTS quite less
attractive to me. Are we sure there isn't a better way?

My 2 cents,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20161125/9aadeba4/attachment.bin>


More information about the Development mailing list