24.01.2019, 17:13, "Jedrzej Nowacki" <[email protected]>: > Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze: >> On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote: >> >> I think that’s fine. What’s much worse is having a fix in 5.12 and not >> >> knowing how to deal with the merge conflicts into dev. That means dev >> >> might >> >> regress, unless whoever authored the change is willing to spend time on >> >> making it work. In the end, if contributors can’t own their changes for >> >> all >> >> various branches of Qt, then I much prefer for them to own the changes at >> >> least for dev. And with Qt 6, this will become a much bigger problem. >> >> Thiago Macieira (23 January 2019 20:10) >> >> > The problem is I can turn this around and say that we introduce >> > regressions >> > into the older branches due to an improper cherry-pick that didn't >> > conflict. >> and *that* is a concern that does bother me. >> Of course, it's got to pass integration, as well as not conflict, >> but that doesn't guarantee it hasn't broken something. > > Of course, but it is not a regression to the current system, we have the > problem currently, right? We can introduce a regression in a release branch by > merging and cherry-picking without conflicts. On the other hand logic that > doesn't apply cleanly has a higher chances of introducing bugs and therefore > higher chance of causing release problems. These changes are more visible in > gerrit as opposite to somehow opaque merges. So in my opinion it is an > improvement.
However, regression in stable branch costs more, as in worst case it can result in brown paper bug being released > > Cheers, > Jędrek > > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
