On Thu, Jan 28, 2021 at 04:48:31PM +, Volker Hilsheimer wrote:
On 22 Jan 2021, at 12:39, Oswald Buddenhagen wrote:
remember that this is only for the commits that explicitly ask for a dep
update, and they currently do that by modifying the yaml file.
So things either work, or they need s
> On 22 Jan 2021, at 12:39, Oswald Buddenhagen
> wrote:
>
> On Thu, Jan 21, 2021 at 04:06:03PM +, Volker Hilsheimer wrote:
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
> for example, the information that a build with updated dependencies is
> required can be stored as an an
On Thu, Jan 21, 2021 at 04:06:03PM +, Volker Hilsheimer wrote:
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
for example, the information that a build with updated dependencies
is required can be stored as an annotation in the commit message
(that's exactly what zuul does, afaik), and th
On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote:
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
for example, the information that a build with updated dependencies is required
can be stored as an annotation in the commit message (that's exactly what zuul
does, afaik), and the in
Reviving this thread as a follow up to the discussion in the “Qt6 repo” thread
at
https://lists.qt-project.org/pipermail/development/2021-January/040902.html
> On 17 Sep 2019, at 14:51, Oswald Buddenhagen
> wrote:
>
> On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote:
>> Am 17.09
On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote:
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
for example, the information that a build with updated dependencies
is required can be stored as an annotation in the commit message
(that's exactly what zuul does, afaik), and the i
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
> On Tue, Sep 17, 2019 at 06:56:39AM +, Simon Hausmann wrote:
>> When the todo list is empty and there are no more pending updates,
>> the batch update is complete. If during that update there were no
>> failures, the Qt Module Updater will al
On Tue, Sep 17, 2019 at 06:56:39AM +, Simon Hausmann wrote:
When the todo list is empty and there are no more pending updates, the
batch update is complete. If during that update there were no failures,
the Qt Module Updater will also push a change to qt5.git with an update
to all submodule
Hi,
I would like to provide an update to this (old) thread based on the
development in the past months and weeks.
Am 15.02.19 um 10:30 schrieb Frederik Gladhorn:
> Hi,
>
> On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote:
>> Summing up the discussion here. It looks like people overall ag
Hi,
On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote:
> Summing up the discussion here. It looks like people overall agree that the
> pinned dependency approach (option 3) sounds better than what we currently
> have. The main concern was CI capacity, but Frederik believes that with
> enoug
Summing up the discussion here. It looks like people overall agree that the
pinned dependency approach (option 3) sounds better than what we currently
have. The main concern was CI capacity, but Frederik believes that with enough
storage capacity for build artefacts this will not be worse than w
Robin Burchell (30 January 2019 10:13)
> I will admit that a monorepo has a _different_ set of problems
> (including but not limited to: longer build times, longer test times,
> flaky tests in unrelated areas blocking changes),
It also makes it easier to cope with API changes, which is great where
On tirsdag 29. januar 2019 11:07:55 CET Alex Blasche wrote:
> >From: Development on behalf of
> >Frederik Gladhorn
> 2 Heads: use the latest revision of each branch (the system we used to have
> in the past)
>
> >3 Modules containing pinned dependency sha1s
> >
> >Each module is complete
On onsdag 30. januar 2019 09:17:11 CET Alex Blasche wrote:
> >From: Development on behalf of Jedrzej
> >Nowacki >
> >Personally, I also do like the idea of monolithic repo, while keeping
> >
> >modularization on the logical / build level. In our current state I see two
> >major problems:
> >- our
On Wed, Jan 30, 2019, at 9:17 AM, Alex Blasche wrote:
> I am clearly missing something here. Could you please outline why such a
> monolithic repo would be good? As you pointed out yourself, the
> conceptual problem that different libraries won't walk in lockstep
> remains and segmented builds c
>From: Development on behalf of Jedrzej
>Nowacki
>Personally, I also do like the idea of monolithic repo, while keeping
>modularization on the logical / build level. In our current state I see two
>major problems:
>- our build is quite monolithic in practice. For example qtbase always needs
>t
On Sunday, January 27, 2019 11:47:04 AM CET Harri Porten wrote:
> On Sat, 26 Jan 2019, Olivier Goffart wrote:
> > I think the "monorepo" is clearly a good approach. And git is evolving
> > with
> > shadow clones and partial checkout. LLVM/Clang recently choose the
> > monorepo
> > approach as it mo
>From: Development on behalf of Frederik
>Gladhorn
2 Heads: use the latest revision of each branch (the system we used to have in
the past)
>3 Modules containing pinned dependency sha1s
>Each module is completely self-contained, that means qt5 is not
>required as such (but may still
Here are the options we discussed internally. I'm happy to elaborate more in
case something is unclear.
1 Do nothing / today / qt5.git
2 Heads: use the latest revision of each branch (the system we used to have in
the past)
3 Modules containing pinned dependency sha1s
Each module is c
On Fri, Jan 25, 2019 at 01:12:11PM +, Frederik Gladhorn wrote:
> qt5.git serves several purposes today, for example:
> - it contains a few binaries needed for Windows development
>
that's rather trivial, and the only reason i didn't fix it years ago is
that factoring these out to another repo w
On Sat, 26 Jan 2019, Olivier Goffart wrote:
I think the "monorepo" is clearly a good approach. And git is evolving with
shadow clones and partial checkout. LLVM/Clang recently choose the monorepo
approach as it moves to git.
Of one problem is that this will make CI integration slower because
On 25.01.19 14:12, Frederik Gladhorn wrote:
Hi all,
I'd like to start another discussion around our development workflow.
We arrived at our current model of Qt modules (in the git repository sense)
and using qt5.git as a container for all of them through a series of steps and
changes. Mix in the
25.01.2019, 18:11, "Allan Sandfeld Jensen" :
> I think for something like qt6, I would like to suggest I think I have brought
> up before in relation to testing qt5.git changes on more platforms or
> configuations: A system for non blocking CI failures.
>
> In WebKit they what they called the CI-
On Freitag, 25. Januar 2019 14:12:11 CET Frederik Gladhorn wrote:
> Hi all,
>
> I'd like to start another discussion around our development workflow.
> We arrived at our current model of Qt modules (in the git repository sense)
> and using qt5.git as a container for all of them through a series of
> -Original Message-
> From: Development On Behalf Of
> Frederik Gladhorn
> Sent: Friday, 25 January 2019 2:12 PM
> To: development@qt-project.org
> Subject: [Development] Qt modules, API changes and Qt 6
>
> Hi all,
>
> I'd like to start anothe
Hi all,
I'd like to start another discussion around our development workflow.
We arrived at our current model of Qt modules (in the git repository sense)
and using qt5.git as a container for all of them through a series of steps and
changes. Mix in the evolution of the testing environment over t
26 matches
Mail list logo
