> Sounds nice, but the reality is that this has not been the case. > Forward-merging hasn't worked without a fair bit of hand-holding; one big > difference is that forward-merging is a centralized process, so the > hand-holidng had to be done by the merge master who has nothing to do with > either the code that’s being modified, or the patch that caused conflicts. > And nobody wants to be the merge-master. > > And who does backwad merges? the CI automatically? Indeed backward merges don't suffer for conflicts
Also (as people confirmed during the discussion at CS) the forward merging > process causes significant delays. Fixing a bug in 5.15 that you would like > to modify to use modern C++, or refactor whatever smelly code you might > have run into, in dev means that you spend weeks on a simple bug fix; > merging it into 5.15; waiting for forward merging (and potentially > integrations) to succeed; adjusting the merged change in dev; merging into > dev. > I don't get this one because even if you push your fix directly to dev you still need to test your fix in previous branches. Furthermore if your fix used a modern C++ syntax chances are that you cannot backport to previous branches. Thus you still need to code the fix for 5.15 C++ syntax, test it in dev, test it in 5.15, integrate in both and then eventually make another commit on dev for porting your fix to new modern c++ syntax. Supposing to have a bot for auto forward merges (as i understood you're supposing to have for backward merges) i don't see any difference. > This kills the motivation to do necessary refacorings and structural code > improvements, which is not good for the project. > Probably. At the same time i've the fear that might increase sloppyness in backporting. > > > Cheers, > Volker > > Thank you for the explanations -- Filippo Cucchetto
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development