> -Original Message-
> From: Development On Behalf Of
> Giuseppe D'Angelo via Development
> Sent: Friday, 25 January 2019 7:23 PM
> To: development@qt-project.org
> Subject: Re: [Development] Archiving is working
>
> Il 25/01/19 18:41, Edward Welbourne ha scritto:
> > The pages have all
On Friday, January 25, 2019 11:08:52 AM CET Lars Knoll wrote:
> This adds a very small risk that two parallel changes don’t conflict during
> the merge/cherry-pick process, but cause a test regression together. To
> help with that, we can simply run a regular status check on the repo. If
> this
On 28.1.2019 15.09, Jedrzej Nowacki wrote:
> On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote:
>> On 24.1.2019 16.15, Edward Welbourne wrote:
>>
>>> Kari Oikarinen (24 January 2019 15:02)
>>>
The rest of the paragraph talks about a situation where we will have two
> -Original Message-
> From: Development On Behalf Of
> Jedrzej Nowacki
> Sent: Monday, 28 January 2019 3:54 PM
> To: Robert Loehning
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: New branch model
>
> On Monday, January 28, 2019 2:38:44 PM CET Robert Loehning
On Friday, January 25, 2019 9:25:16 AM CET Simon Hausmann wrote:
> I'm somewhat attracted to the proposed model, in conjunction with automation
> and by treating Qt6 differently.
>
> However Allan's last point is what sticks to me most, the load on the CI and
> the resulting impact on
On Thursday, January 24, 2019 7:46:35 PM CET Sergio Ahumada wrote:
> On 24.01.19 14:10, Edward Welbourne wrote:
> > Automated cherry-picking implies various complications that we haven't
> > fully explored; whereas merges have some well-established reliable
> > properties that avoid many of those
On Thursday, January 24, 2019 10:29:13 PM CET Ville Voutilainen wrote:
> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann wrote:
> > I would see the biggest long term impact with the massive amount of cherry
> > picks from dev to qt6 over a long period of time.
> >
> > Git rerere works locally, so
>From: Development on behalf of Edward
>Welbourne
Volker Hilsheimer (28 January 2019 13:54) agreed:
>> Indeed; esp in the cases where a causal contribution comes in, and
>> where then the maintainers need to invest time to decide whether or
>> not this is material for a stable branch, dev
On Monday, January 28, 2019 2:38:44 PM CET Robert Loehning wrote:
> Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki:
>
> > On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> >
> >>> Testing whether the bug that I’m fixing exists in dev or not is part of
> >>> the drill of fixing
>From: Development on behalf of Jedrzej
>Nowacki
>> I mean an external project which is based on Qt, like some commercial
>> application. Say they decided - for good or bad reasons - that they will
>> not migrate to Qt 6, but they require a fix in Qt
Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 08:03, Olivier Goffart wrote:
>> [...]>- Stay with the current solution <= the merge effort is too big
>> and qt6 is
>>> expected to cause conflicts that really should not be solved by one person
>>
>> Again, I don't see
Am 28.01.2019 um 13:54 schrieb Volker Hilsheimer:
>> On 28 Jan 2019, at 13:36, Martin Smith wrote:
>>> On 28 Jan 2019, at 13:27, Robert Loehning wrote:
Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
> On 24 Jan 2019, at 08:03, Olivier Goffart wrote:
> [...]>- Stay with the
> On 28 Jan 2019, at 14:03, Robert Loehning wrote:
> Am 28.01.2019 um 13:54 schrieb Volker Hilsheimer:
>>> On 28 Jan 2019, at 13:36, Martin Smith wrote:
On 28 Jan 2019, at 13:27, Robert Loehning wrote:
> Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 08:03,
On Friday, January 25, 2019 2:17:15 PM CET Edward Welbourne wrote:
> On 25 Jan 2019, at 10:10, Simon Hausmann
mailto:simon.hausm...@qt.io>> wrote:
> >> I think it's worthwhile to develop the tooling to automate
> >> cherry-picking. That tooling is something that is perhaps best tried
> >> on a
>That's laudable, but a non-professional developer who just submitted a
>fix and doesn't follow all the other changes going on might have a
>different opinion.
Wouldn't we expect those external patchers to submit changes to dev only? Then
the module maintainer, or an LTS version maintainer (is
On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> > Testing whether the bug that I’m fixing exists in dev or not is part of
> > the drill of fixing bug, isn’t it? Why would you spend time on fixing
> > something in 5.12 without checking whether the issue is still present in
> >
Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
The whole notion that my change has to become someone else’s problem
by design of the merge process is more than just a little crazy to
me. I want to own my change, have control over which branches it
hits, and be responsible
On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote:
> On 24.1.2019 16.15, Edward Welbourne wrote:
>
> > Kari Oikarinen (24 January 2019 15:02)
> >
> >> The rest of the paragraph talks about a situation where we will have two
> >> stable
branches alive at the same time. Typically
> -Original Message-
> From: Development On Behalf Of
> Tony Sarajärvi
> Sent: Thursday, January 17, 2019 2:23 PM
> To: development@qt-project.org
> Subject: [Development] Good idea to update Windows 10 to 1809 - Redstone
> 5?
>
> Hi
>
> We have this thing that we like to try to update
On Friday, January 25, 2019 11:50:55 AM CET Eike Ziller wrote:
> Note that this risk exists partially even if fixes are first pushed into dev
> and then from dev directly to multiple “stable” branches.
>
> Fix goes into dev.
> Fix is cherry-picked into 5.9 without issues.
> Fix is cherry-picked
> On 28 Jan 2019, at 13:36, Martin Smith wrote:
>> On 28 Jan 2019, at 13:27, Robert Loehning wrote:
>>> Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
On 24 Jan 2019, at 08:03, Olivier Goffart wrote:
[...]>- Stay with the current solution <= the merge effort is too big
On Thursday, January 24, 2019 2:35:51 PM CET Allan Sandfeld Jensen wrote:
> We can't integrate multiple changes to the same branch in parellel. So you
> can't start using more resources to speed things up. (9 women to have a
> child in 1 month) The only way to speed up CI integration is to be
On 1/28/19 1:26 PM, Shawn Rutledge wrote:
>
>
>> On 28 Jan 2019, at 09:43, Mitch Curtis wrote:
>>
>>> -Original Message-
>>> From: Development On Behalf Of
>>> Giuseppe D'Angelo via Development
>>> Sent: Friday, 25 January 2019 7:23 PM
>>> To: development@qt-project.org
>>> Subject:
> On 28 Jan 2019, at 09:43, Mitch Curtis wrote:
>
>> -Original Message-
>> From: Development On Behalf Of
>> Giuseppe D'Angelo via Development
>> Sent: Friday, 25 January 2019 7:23 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] Archiving is working
>>
>> Il
Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki:
> On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
>>> Testing whether the bug that I’m fixing exists in dev or not is part of
>>> the drill of fixing bug, isn’t it? Why would you spend time on fixing
>>> something in 5.12 without
On Friday, January 25, 2019 1:30:52 PM CET Shawn Rutledge wrote:
> > On 25 Jan 2019, at 09:43, Martin Smith wrote:
> >
> >
> >> It is the absolute exception that a change goes into qtbase on first
> >> attempt.
>
> >
> > But many rejections have nothing to do with any change at all. I often
>
On Monday, 28 January 2019 04:54:58 PST Volker Hilsheimer wrote:
> A change making it into dev where it can be noticed and scrutinized by a
> bunch of people that didn’t participate in the merge request, where it can
> pass additional build and configurations, and generally be exposed to
>
Hi,
We have soft branched '5.13' from 'dev' now. Final downmerge and Qt 5.13
Feature Freeze will happen Friday 1st February. So please start using '5.13'
now for new changes targeted to Qt 5.13 release
br,
Jani Heikkinen
Release Manager
___
Jedrzej Nowacki (Monday, 28 January 2019 3:54 PM)
>> We have the same problem right now, just in the opposite
>> direction. One want to fix version 5.9, why the person should help
>> with merging and solving problems in 5.12? At least the problem would
>> be visible in gerrit as an not staged
On Mon, Jan 28, 2019 at 12:54:58PM +, Volker Hilsheimer wrote:
> > Wouldn't we expect those external patchers to submit changes to dev
> > only? Then the module maintainer, or an LTS version maintainer (is
> > there a maintainer for each LTS version?) would decide whether the
> > change should
On 28.01.19 14:37, Jedrzej Nowacki wrote:
>>
>> disadvantages:
>> - most developers don't know how to handle the propagation failures
>> -- I already moved on and am working on something else, do you want me
>> to switch to '5.19' to fix a change I did in '5.12' ? oh, and it failed
>> in '5.18' as
On Montag, 28. Januar 2019 14:53:21 CET Kai Koehne wrote:
> > -Original Message-
> > From: Development On Behalf Of
> > Tony Sarajärvi
> > Sent: Thursday, January 17, 2019 2:23 PM
> > To: development@qt-project.org
> > Subject: [Development] Good idea to update Windows 10 to 1809 -
Hi,
Apparently there hasn't been any email notification about maintenance break
made by IT this morning. Sorry about that.
Our whole network was down so nothing has been working for a while. Everything
should be back online now, but we are still checking if there's something that
didn't come
Am 28.01.2019 um 11:11 schrieb Edward Welbourne:
> Am 25.01.2019 um 11:08 schrieb Lars Knoll:
>>> The CI problem comes from the fact that if we have a high rate of
>>> stages to qtbase/dev, we at some point get into a deadlock situation,
>>> even if we disregard any flakiness in the system. That’s
Congratulations to Jannis. Alle rights have been set.
--
Alex
From: Development on behalf of Maurice
Kalinowski
Sent: Monday, 7 January 2019 1:35:41 PM
To: development@qt-project.org
Subject: [Development] Nominating Jannis Völker for Approver
Hi,
I
Am 25.01.2019 um 11:08 schrieb Lars Knoll:
>> The CI problem comes from the fact that if we have a high rate of
>> stages to qtbase/dev, we at some point get into a deadlock situation,
>> even if we disregard any flakiness in the system. That’s because
>> higher rates imply that more changes are
36 matches
Mail list logo
