[Development] Proposal: New branch model

Konstantin Tokarev annulen at yandex.ru
Thu Jan 24 15:17:22 CET 2019

24.01.2019, 17:13, "Jedrzej Nowacki" <jedrzej.nowacki at qt.io>:
> 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
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development


More information about the Development mailing list