[Development] Suggestion to add labels when changing API

[Adam Treat]

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