[Development] Suggestion to add labels when changing API

[Liang Qi]

I really don’t think switch back to a monolithic repo is a good idea…

But if I understand atomic commits across submodules as successful integrations in qt5, I think it has some meaning to me. Here are a few tasks which I think perhaps related with this topic.

https://bugreports.qt.io/browse/QTBUG-19580
https://bugreports.qt.io/browse/QTQAINFRA-824

— Liang

> On 7 Dec 2017, at 18:17, Adam Treat <adam.treat at qt.io> wrote:
> 
> Hi,
> 
> I think it is high time that we fix the underlying problem: supporting atomic commits across submodules.
> 
> Once this is done we should revert our CI to test changes against latest version of all modules. As for how this could be done:
> 
> * Adopt something like Google's repo tool: https://code.google.com/archive/p/git-repo/
> * Stop using submodules and use a monolithic repo
> * Git subtree
> * Implement atomic commit across submodules not in Git, but in the gerrit/COIN layer so that COIN effectively locks integrations until commits that span submodules are finished
> * Something else?
> 
> Cheers,
> Adam
> 
> On 12/07/2017 11:22 AM, Liang Qi wrote:
>> Since http://lists.qt-project.org/pipermail/development/2016-October/027542.html , Coin tests all changes against Qt5 instead of the latest version of all modules.
>> 
>> The situation is sth like, some new APIs were added to qtbase in 5.10, and other modules were adapted. But around beta or sometime(before release), some refactoring work happened on those APIs. We adjusted them in qtbase, and other modules. We have several steps to make sure those thing to be approved in CI/COIN. But the order of things gets lost easily when merging the changes up, for example to the dev branch.
>> 
>> Here are some suggestions to make those steps more clearer to the people who maintain merge and integration.
>> 
>> The changes that are important to be merged up before other changes should have a special tag, such as API_CHANGE in the commit message. Then the script used to do the merges could stop and/or warn about commits with this tag in the message, which would make the merge easier. We can also apply this check into the submodule update script.
>> 
>> The situation is also valid for some private API changes(which were used cross qt submodules).
>> 
>> About which labels are better to be used for this purpose, please give your suggestion and votes. Thanks.
>> 
>> Best Regards,
>> Liang
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development