[Development] Proposal: New branch model

[Allan Sandfeld Jensen]

On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote:
> More people working and building against dev helps keep dev more stable (by
> virtue of discovering breakage sooner), and the proposal encourages more
> people to work on dev. That can be a good thing.
 
No,  it will overload the CI by having all integrations happen on the same 
branch, instead being able to integrate multiple branches at once.

> Urgency to get fixes into a stable branch is an argument that has come up a
> few times. The current 5.12.1 release seems to be delayed because some
> changes made it into 5.12 that shouldn’t have been there in the first place
> (given the definition of “stable”). It would be interesting to see some
> data about how many point releases we had to delay because “highly
> desirable fix for old bug was stuck in the process” vs “regression was
> introduced in a stable branch and only discovered during release testing”.
> 
I dont see that. 5.12.1 branched a long time ago and very early, patches in 
5.12 shouldnt affect it. It is stalled because certain things needs to be 
fixed that arent fixed.

> Without data, I would speculate that perhaps a model that leads to fewer
> changes made to stable branches because it requires an explicit decision
> (and perhaps extra work) to get changes there is not such a terrible idea.
> And making the work to make changes to a stable branch, ie the cost of
> maintenance, very visible is also a good thing.
 
> Either way, nothing in the proposal prevents us from developing and push a
> fix for 5.12, and then develop a different fix for dev that we don’t cherry
> pick into 5.12 or other stable branches. This should be an exception, used
> in urgent situations where indeed we can’t wait. For those cases, there’s
> no merge conflict in the first place in the new model (because there’s no
> merge).
 
It is still doing merging the wrong way for no good reason. Even if cherry-
picking itself wasnt a bad idea. You could just as well commit to the stable 
branch first and then cherry-pick it to the other branches. That way there 
would be no need for cryptic annotations, the branches to pick to would be 
implicit from where the patch first landed. Or even better, you could perform 
a merge to dev on every single commit to the stable branch, or even better, 
only create a merge if there are conflicts, so we don't overload the CI on 
dev.

'Allan