On 08.12.2017 20:52, Adam Treat wrote:
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 trig
08.12.2017, 22:53, "Adam Treat" :
> 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 prob
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. O
On 12/08/2017 09:20 AM, Konstantin Tokarev wrote:
08.12.2017, 17:14, "Tor Arne Vestbø" :
On 08/12/2017 14:54, Sergio Ahumada wrote:
an old concept that used to pin the sha1 of repo/module's dependency, eg
http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544
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
08.12.2017, 18:50, "Oswald Buddenhagen" :
> 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
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
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 ab
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.
On 12/08/2017 09:20 AM, Konstantin Tokarev wrote:
08.12.2017, 17:14, "Tor Arne Vestbø" :
> On 08/12/2017 14:54, Sergio Ahumada wrote:
>> an old concept that used to pin the sha1 of repo/module's dependency, eg
>>
>>
>> http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012
>>
>> that was r
On 08/12/2017 14:54, Sergio Ahumada wrote:
an old concept that used to pin the sha1 of repo/module's dependency, eg
http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012
that was replaced in, eg,
http://code.qt.io/cgit/qt/qtdeclarative.g
On 08.12.2017 14:23, Edward Welbourne wrote:
On 07/12/2017 17:22, Liang Qi wrote:
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 wi
On 07/12/2017 17:22, Liang Qi wrote:
>> 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 wo
On 07/12/2017 17:22, Liang Qi wrote:
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 mak
On Thu, Dec 07, 2017 at 10:28:36PM +, Liang Qi wrote:
> 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
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/QT
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://co
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(
18 matches
Mail list logo
