Hi all,
Some of us have been discussing on IRC whether to apply again to the Google
Summer of Code 2019, as The Qt Project.
The deadline for organizations to send applications is February 6th.
The current idea is that, unless there are strong objections against applying,
we will try to submit
On Wednesday, January 30, 2019 1:55:41 PM CET Allan Jensen wrote:
> On Wednesday, 30 January 2019 13:38:46 CET Jedrzej Nowacki wrote:
> > On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote:
> > > On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> > > > Jedrzej
On Wednesday, 30 January 2019 13:38:46 CET Jedrzej Nowacki wrote:
> On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote:
>
> > On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> >
> > > Jedrzej Nowacki (30 January 2019 11:08)
> > >
> > >
> > > > Mårten pointed
On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote:
> On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> > Jedrzej Nowacki (30 January 2019 11:08)
> >
> > > Mårten pointed out that we can check for conflicts up front. Not only
> > > against HEAD of the target
On Wednesday, January 30, 2019 11:19:07 AM CET Edward Welbourne wrote:
> > Mårten pointed out that we can check for conflicts up front. Not only
> > against HEAD of the target branch, but also against all build branches.
> > That is even nicer as there is no need to start a job that would likely
>
Good point. I only just now saw & read the entire tooltip for WebEngine.
I agree that it feels like user error, but it's too easy to make this error.
Also the cost is quite high, I only discovered the issue after a full Qt
download & install & rebuild failed on my code. That's half a day
On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> Jedrzej Nowacki (30 January 2019 11:08)
>
> > Mårten pointed out that we can check for conflicts up front. Not only
> > against HEAD of the target branch, but also against all build branches.
> > That is even nicer as there is
This suggestion is already in JIRA see
https://bugreports.qt.io/browse/QTBUG-71579
Br
Michal
On 01/30/2019 11:29 AM, Kai Koehne wrote:
>> -Original Message-
>> From: Development On Behalf Of
>> Mark De Wit
>> Sent: Wednesday, January 30, 2019 11:13 AM
>> To:
> -Original Message-
> From: Development On Behalf Of
> Mark De Wit
> Sent: Wednesday, January 30, 2019 11:13 AM
> To: development@qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
>
> Selecting MSVC 2015 64-bit + Qt WebEngine for 5.12.1 in
Jedrzej Nowacki (30 January 2019 11:08)
> Mårten pointed out that we can check for conflicts up front. Not only against
> HEAD of the target branch, but also against all build branches. That is even
> nicer as there is no need to start a job that would likely to be rejected at
> the end.
That'll
Selecting MSVC 2015 64-bit + Qt WebEngine for 5.12.1 in the installer does not
give me WebEngine. Is that intentional? Should the installer perhaps warn
that the selected combination is unsupported?
I shall try again with MSVC 2017...
KR,
Mark
-Original Message-
From: Development
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
Il 30/01/19 10:29, Christian Gagneraud ha scritto:
I do not know what is going on with the mailing list archive, but this
is getting frustrating.
Trying to move forward and keep positive, i would like to report on
a(nother) use case here:https://bugreports.qt.io/browse/QTBUG-71225
This bug
On Wednesday, January 30, 2019 10:41:02 AM CET Jedrzej Nowacki wrote:
> Cheap (a.k.a reasonably fast to implement) proposal:
> - Stage button would create a stage branch as currently (through cherry-pick
>
on top of target branch)
> - 3-5 minutes old stage branch would changed to be a build
> -Original Message-
> From: Development On Behalf Of
> Christian Gagneraud
> Sent: Wednesday, 30 January 2019 10:30 AM
> To: interest ; development project.org>
> Subject: [Development] Mailing list archive annoyance
>
> Hi all,
>
> I do not know what is going on with the mailing
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
On Friday, January 25, 2019 11:08:52 AM CET Lars Knoll wrote:
> To me this means we need to seriously rethink that part of our CI system,
> and ideally test changes (or patch series) individually and in parallel. So
> maybe we should adjust our CI system that way:
>
> * test changes (or patch
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:
> >-
Hi all,
I do not know what is going on with the mailing list archive, but this
is getting frustrating.
Trying to move forward and keep positive, i would like to report on
a(nother) use case here: https://bugreports.qt.io/browse/QTBUG-71225
This bug report starts with a couple of links to the Qt
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
Hi,
Very little content yet at: https://wiki.qt.io/New_Features_in_Qt_5.13
There has been many changes worth mentioning pushed to dev during the past 6
months. Please add these to wiki.
I hope that by end of this week we have much more content in the page as Alpha
release milestone is
>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
22 matches
Mail list logo
