[Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 2:17:15 PM CET Edward Welbourne wrote:
> On 25 Jan 2019, at 10:10, Simon Hausmann 
<Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> wrote:
> >> I think it's worthwhile to develop the tooling to automate
> >> cherry-picking. That tooling is something that is perhaps best tried
> >> on a release branch first.
> >> 
> >> I do quite like what Allan suggested: We could try the cherry-pick
> >>
> >>the other way around. Volker, Lars, Thiago etc. surely remember the
> >>p4i script we used to have when we were using Perforce. Imagine that
> >>with more automation.
> 
> Lars Knoll (25 January 2019 11:08)
> 
> > The risk with this is that we might end up having fixes in a stable
> > branch that don’t make it do dev for various reasons, so it’ll regress
> > in the next minor release.
> 
> It should be fairly trivial to ensure we tag the cherry-picks in such a
> way that some routine script can alert relevant folk to ones that
> haven't been sorted out within a month, or before the next release on
> the branch they targeted.  I think this is less of a reason to worry
> than you suppose.
> 

Actually, I share the concern about regressions, if we turn the cherry-pick 
direction. Yes, we can detect such situations, but it is not given that anyone 
would act on it. What if an author is not responding or not doing anything 
about the dev cherry-pick? Who will volunteer to fix the situation? What if, it 
is actually hard task and it can not be done during a release time window?

I really prefer a system that automatically tries to not regress. I believe in 
transparency; maintenance of stable branch is a cost and cherry-pick from dev 
to stable shows the cost.

Cheers,
  Jędrek