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

[Lars Knoll]

The merging has become a huge burden on more than one person. Distributing it over every developer has a couple of positive side effects:

* The code bases have deviated quite a bit in certain areas (c++11 usage, configuration system, removal of WinCE to name just some examples) to make merges difficult and prone to errors. I've seen at least one merge where the merge was actually resolving things the wrong way. And you can't blame the merge masters for it, it's simply too easy to make mistakes there, especially if you don't know the code in question very well

* Developers can usually back port their changes very quickly. They know the code in question, and as it's a single (usually small/localized) change, resolving any conflicts is in almost all cases straight forward. This is not the case when merging 50 unrelated commits

* We will not continuously get C++98 idioms merged back into our development code line

* 5.6 is a stable LTS branch. This does not means that we should fix every possible bug in there. It also doesn't mean we will automatically add support for any new OS version that comes out in there. The most important objective of the branch is to give our customers a stable base for longer lived projects. 

This means we need to be very careful to avoid regressions. And that means limiting changes in the branch. Mainly have critical and security fixes in there, and little else. The new branching scheme will support this nicely. It'll focus our R&D efforts onto 5.8/dev, back-porting critical fixes when required.

> On 25 Nov 2016, at 21:11, Oswald Buddenhagen <Oswald.Buddenhagen at qt.io> wrote:
> 
> On Fri, Nov 25, 2016 at 08:41:42PM +0100, André Pönitz wrote:
>> On Fri, Nov 25, 2016 at 05:09:30PM +0100, Giuseppe D'Angelo wrote:
>>> 1) The whole motivation for stop doing merges from 5.6 forward is the
>>> high number of conflicts between the branches.
>> 
>> That's not true, it's also about the time it takes for a patch to
>> trickle down from 5.6 to dev to enable dependent work there.
>> 
> that only makes sense when you add the word "integrating" here. because
> nothing is stopping you from having said changes cherry-picked locally.
> this even extends to whole teams, if the involved people are capable of
> using git beyond the three basic commands.

True, but it still keeps some part of your mindshare distracted, as you wait for the feature to trickle down. The long merge chain also causes additional overhead and potential delays when trying to get releases out, so it does have a cost for the project as a whole.

Cheers,
Lars


> 
>>> This makes using a LTS quite less attractive to me.
>> 
>> Using with what hat on? People with a "end user programmer hat" want
>> something stable there, no new features.
>> 
> who's talking about features?
> and if you don't want _any_ changes, then you obviosly don't need to
> update.
> 
>> People with a "Qt developer hat" do not want to wait weeks for
>> dependendecies to trickle down.
>> 
> only those who appear to be constantly chased by the devil himself. i
> have no problem whatsoever to do followup work while earlier changes
> wait for integration.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development