On 23 Jan 2019, at 17:20, Mitch Curtis <[email protected]<mailto:[email protected]>> wrote:
[…snip…] Advantages: - no waiting for merges, a fix can be used right away after integration Sounds nice! - faster propagation of fixes targeting all branches, as there are no merges of merges - simpler for new contributors, always push to dev - in most cases a reviewer does no need to know what the current version number is - conflict resolution is distributed and affects mostly the author of the change Do I understand this correctly: conflicts would happen when the initial patch is pushed to dev and on each subsequent cherry-pick that the bot pushes? Potentially, yes. The real advantage is that I, as the developer responsible for the change, can decide how to make it work in more stable branches. Anything from “don’t care” to “I know it works in LTS" to “make a completely different fix with separate code review for the LTS” - my decision, which I can verify locally. Ie distributed conflict resolution, vs “the one person watching over the integration has to deal with all the conflicts”. - documents a change intent, which may be useful for people keeping own forks - over time with increased amount of conflicts old branches, in natural way, stay untouched What does this mean? It becomes less likely that we try to make fixes that work in dev and e.g 5.12 also work in 5.9 if the change doesn’t apply cleanly. That means fewer risky changes in older branches. It also means fewer fixes in older branches, but the decision what to fix or not for a certain release is somewhat orthogonal. If we decide that a fix is needed for 5.9.x, then this model doesn’t stop us from investing the time on making the change. Disadvantages: - git history would be a bit wilder, "git branch --contains" would not work This would be a bit of a pain for me personally, as I use this command often to e.g. know if I have a certain fix. Would there be an alternative command? It’s rather trivial to create a script for this, as long as we use cherry-pick -x Besides, since we do use cherry-picking already today for some branches, git branch —contains already produces incomplete/incorrect results. […snap…] What if we need a release blocker fix, right now! ------------------------------------------------- The setup prioritize dev. So a release branch would get a fix with a delay of one dev integration. So in the end, in terms of number of integrations, it's kinda similar to the current approach where the change has to go through two CI integrations? E.g. the original change in qtdeclarative.git and then the qt5 submodule update before that code can be used in a dependent module like qtquickcontrols2.git? This proposal doesn’t change anything about that. Volker
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
