[Development] Suggestion to add labels when changing API

[Konstantin Tokarev]

08.12.2017, 22:53, "Adam Treat" <adam.treat at qt.io>:
> On 12/08/2017 12:47 PM, Sergio Ahumada wrote:
>>  On 08.12.2017 16:50, Oswald Buddenhagen wrote:
>>>  On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote:
>>>>  On 08.12.2017 15:42, Adam Treat wrote:
>>>>>  Relying upon qt5 submodule pins is the problem. The underlying
>>>>>  issue is
>>>>>  atomicity of commits. Oswald is right.
>>>>>
>>>>>  We need to have a way to provide atomic commits across modules at
>>>>>  least
>>>>>  the CI should see these as atomic and integrate accordingly.
>>>>
>>>>  what about trying to enable gerrit topic's feature again for cross-repo
>>>>  changes?
>>>  from the ci perspective, that's both pointless (because the grouping can
>>>  be achieved temporally by just staging the changes at the same time) and
>>>  insufficient (because the system currently just won't do atomic
>>>  integrations).
>>
>>  I meant provided the system is able to do atomic integrations, as Adam
>>  suggested. But that would probably require quite a lot of more
>>  computer power.
>
> Why?

Because if you rebuild all modules when integrating each commit to qtbase,
it will require much more CPU (and wall clock) time than now. Note that qtbase
probably has higher commit rate than some "peripheral" modules.

>
>>  actually, Adam's initial proposal sounds quite good to me
>>
>>  > * Adopt something like Google's repo tool:
>>  https://code.google.com/archive/p/git-repo/
>>  > * Stop using submodules and use a monolithic repo
>>
>>  for both these proposals see https://bugreports.qt.io/browse/QTBUG-19580
>>
>>  > * 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
>>
>>  Use the topic feature to merge changes across repos once they are all
>>  passed their CIs. Merge normal changes as usual after their CIs are
>>  passed.
>>
>>  Move the old dependencies from
>>  sync.profile+http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules to the
>>  demo-default.xml file proposed in QTBUG-19580 .. get the list of repos
>>  to be cloned (or already built tgz) + needed sha1 to git-reset and
>>  then git-cherry-pick the changes under test on top ..
>>
>>  does that make any sense?
>
> As another alternative I'm trying to figure out if Gitlab's CI system
> has a way to deal with this:
>
> https://forum.gitlab.com/t/trigger-ci-build-if-any-dependent-git-repo-is-updated/9725
>
> They do have ways to kick off integration jobs based on git triggers
> and/or other logic: https://docs.gitlab.com/ee/ci/yaml/#jobs
>
> I think we could design atomic integrations across submodules with
> something like that.
>
> In general, has anyone looked into Gitlab's CI system and
> compared/contrasted with COIN?
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin