On 25.01.19 21:11, Christian Ehrlicher wrote:
Hello,
The two implicit conversions from QByteArray to const char*/void*
(QByteArray::operator const char *() and QByteArray::operator const void*())
were marked as obsolete with Qt5.0 but never get decorated as such. This means
their usage even
Am 26.01.2019 um 08:22 schrieb Olivier Goffart:
On 25.01.19 21:11, Christian Ehrlicher wrote:
Hello,
The two implicit conversions from QByteArray to const char*/void*
(QByteArray::operator const char *() and QByteArray::operator const
void*()) were marked as obsolete with Qt5.0 but never get
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
It's a fair point to raise.
The closest scenario that I can think of that we've had in the past with a long
living branch was 5.6 before it entered cherry-picking mode. The first change
to qtbase 5.6 was uploaded to Gerrit on August 11th 2015. The last merge that I
can see away from 5.6 was
> On 25. Jan 2019, at 11:08, Lars Knoll wrote:
>
>
>
>> On 25 Jan 2019, at 10:10, Simon Hausmann 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 release branch
>> first.
>>
>> I do
+1 without any hesitation. (I thought he was an approver already :)
Simon
From: Development on behalf of Kari
Oikarinen
Sent: Friday, January 25, 2019 9:06:29 AM
To: development@qt-project.org
Subject: [Development] Nominating Sami Nurmenniemi for Approver
>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 submit
documentation-only changes to QtBase, and they often get tested alone, with no
other changes. They still get rejected multiple times
On Friday, 25 January 2019 09:05:45 CET Lars Knoll wrote:
> * I think it makes the life of casual/new contributors easier. Simply always
> develop and push against the development branch. The more experienced
> reviewer can then easily decide that the fix should be cherry-picked into a
> stable
How would the CI load not change? Rather than one merge bringing multiple
commits, each change would still be picked individually.
I also think the cherry-picking model makes more sense when branches with less
action get the cherry-picks. The cherry-picking conflict issues grow as the
amount of
> Original Message-
> From: Thiago Macieira
>
> But we WILL NOT change from UTF-16 in the next 2 years.
From a user standpoint, this seems perfectly Ok to me.
I do not buy the argument that if switching QString to utf8 make developer bugs
appear sooner, this is a good thing.
Most
On 25.1.2019 12.43, Ville Voutilainen wrote:
> On Fri, 25 Jan 2019 at 10:22, Teemu Holappa wrote:
>>
>> Hello All,
>>
>> I'd like to nominate Kimmo Ollila for Approver. He has joined The Qt Company
>> more than five years ago. Lately he has been working on INTEGRITY RTOS
>> support and
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 release branch first.
I do quite like what Allan suggested: We could try the
> On 24 Jan 2019, at 22:29, 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 it
On Fri, 25 Jan 2019 at 10:22, Teemu Holappa wrote:
>
> Hello All,
>
> I'd like to nominate Kimmo Ollila for Approver. He has joined The Qt Company
> more than five years ago. Lately he has been working on INTEGRITY RTOS
> support and maintenance.
+1.
+1
Thank Sami for lots of help on QEMU build and etc.
—Liang
> On 25 Jan 2019, at 09:06, Kari Oikarinen wrote:
>
> Hi!
>
> I'd like to nominate Sami Nurmenniemi for Approver. He has already been
> working
> in The Qt Company in the same team as I am for a good while.
>
> Sami has worked on
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 productivity:
If all it would take to get changes distributed is a cherry-pick,
I think it's worthwhile to develop the tooling to automate cherry-picking. That
tooling is something that is perhaps best tried on a release branch first.
I do quite like what Allan suggested: We could try the cherry-pick the other
way around. Volker, Lars, Thiago etc. surely remember the p4i
On Thu, Jan 24, 2019 at 10:57 PM Thiago Macieira
wrote:
>
> On Wednesday, 23 January 2019 23:32:28 PST Olivier Goffart wrote:
> > - Introduce some iterator that iterates over unicode code points.
>
> I wrote that about a decade ago. It's called QStringIterator and it's inside
> our sources, but
First the change would need to land in the targeted branch, then the
cherry-picks to other branches.
Batching and controlled intervals are possible, but taken to an extreme they
would replicate the current load as a group of commits would be taken in a
single build as with merges currently. If
Hi!
I'd like to nominate Sami Nurmenniemi for Approver. He has already been working
in The Qt Company in the same team as I am for a good while.
Sami has worked on (among other things):
- Improving flaky tests
- CI coverage for ARM platforms by using user mode QEMU
- Demos for embedded devices
Hello All,
I'd like to nominate Kimmo Ollila for Approver. He has joined The Qt Company
more than five years ago. Lately he has been working on INTEGRITY RTOS support
and maintenance.
Here is the list of his changes:
https://codereview.qt-project.org/#/q/owner:+kiollila,n,z
and the list of
The first attempt at getting a change in is distributed over multiple branches.
The staging of the cherry-pick can happen in batches and controlled intervals
as with merges.
Simon
From: Kari Oikarinen
Sent: Friday, January 25, 2019 10:41:21 AM
To: Simon
On Fri, 25 Jan 2019 at 10:31, Simon Hausmann wrote:
>
>
> +1 without any hesitation. (I thought he was an approver already :)
+1.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
> 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 submit
> documentation-only changes to QtBase, and they often get tested alone, with
Arnaud Clère (25 January 2019 10:59) wrote:
> Most user code I have written or seen handles text data naively and is
> incorrect in some respect but I think only a minority of if is leading
> to real problems because input data will rarely trigger them.
That depends a lot on who's supplying your
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
Am 24.01.2019 um 10:39 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 09:22, Jaroslaw Kobus wrote:
"All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch
cherry-
pick, would be taken
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
> -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 another discussion around our development
Hi all,
Again, our sysadmins claim they've fixed what was broken in the
archives. Please check up on any archives in which you've seen holes
lately and let us know if there are still any problems.
If all's well, I'll hope our archives are stable again and begin going
through all our QUIPs
Looks like the index was also regenerated for October 2016,
[Development] Coin news - Jedrzej Nowacki
Tue Oct 25 10:22:41 EEST 2016
Current link:
https://lists.qt-project.org/pipermail/development/2016-October/055084.html
It was:
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 release branch first.
>>
>> I do quite like what Allan suggested: We could
Am 25.01.2019 um 11:08 schrieb Lars Knoll:
>
>
> 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 release branch
>
Liang Qi (25 January 2019 14:17)
> Looks like the index was also regenerated for October 2016,
>
> [Development] Coin news - Jedrzej Nowacki
> Tue Oct 25 10:22:41 EEST 2016
>
> Current link:
> https://lists.qt-project.org/pipermail/development/2016-October/055084.html
>
> It was:
>
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
> By all means, let's make sure the internals are efficient for the more
> common languages and scripts; but it's way past time to start doing
> Unicode properly, so that all cultures are well-served by default, when
> the software folk are using is built on Qt,
I don't think anyone knows what
25.01.2019, 01:02, "Thiago Macieira" :
> On Thursday, 24 January 2019 05:06:58 PST Konstantin Tokarev wrote:
>> I will be officially pissed off if possibility to access raw data of QString
>> without extra copy is gone It would be better if there is a way to figure
>> out internal storage
Den fre 25 jan. 2019 kl 19:23 skrev Giuseppe D'Angelo via Development
:
>
> Il 25/01/19 18:41, Edward Welbourne ha scritto:
> > The pages have all been updated and had their URLs changed.
> > Or are you trying to tell me something else ?
> > I'm not sure I fully understand.
>
> Yes. And that's the
Hello,
The two implicit conversions from QByteArray to const char*/void*
(QByteArray::operator const char *() and QByteArray::operator const
void*()) were marked as obsolete with Qt5.0 but never get decorated as
such. This means their usage even inside QtBase is huge (I would say at
least
On Friday, 25 January 2019 12:11:33 PST Christian Ehrlicher wrote:
> Hello,
>
> The two implicit conversions from QByteArray to const char*/void*
> (QByteArray::operator const char *() and QByteArray::operator const
> void*()) were marked as obsolete with Qt5.0 but never get decorated as
> such.
On Friday, 25 January 2019 04:54:22 PST Edward Welbourne wrote:
> we
> fail to properly support cultures whose scripts are relegated to the
> outer planes of Unicode - as, for example, the Chakma language's number
> system
All living languages are supposed to be stored in the BMP, which means no
On Friday, 25 January 2019 08:54:38 PST Konstantin Tokarev wrote:
> > How often do you need that, oustide of QString itself? And maybe a few
> > efficient QtCore classes? (QCborValue comes to mind)
>
> Each time I need to interact efficiently with extenal code which isn't
> Qt-based, e.g. WebKit,
Il 25/01/19 18:41, Edward Welbourne ha scritto:
The pages have all been updated and had their URLs changed.
Or are you trying to tell me something else ?
I'm not sure I fully understand.
Yes. And that's the problem. It *MUST NOT* happen. Links to mails in the
mailing list are found in commit
Il 25/01/19 10:49, Dominik Haumann ha scritto:
Sidenote: Such a QStringIterator would also be helpful for
KTextEditor, where we likely have some bugs we usually never see since
we never have > UTF16 or composed characters.
I've managed to merge it in QtCore some 5 years ago, comes with docs
Am 25.01.2019 um 21:23 schrieb Thiago Macieira:
On Friday, 25 January 2019 12:11:33 PST Christian Ehrlicher wrote:
Hello,
The two implicit conversions from QByteArray to const char*/void*
(QByteArray::operator const char *() and QByteArray::operator const
void*()) were marked as obsolete with
On Friday, 25 January 2019 01:10:35 PST Simon Hausmann wrote:
> I do quite like what Allan suggested: We could try the cherry-pick the other
> way around. Volker, Lars, Thiago etc. surely remember the p4i script we
> used to have when we were using Perforce. Imagine that with more
> automation.
I
On Friday, 25 January 2019 04:30:52 PST Shawn Rutledge wrote:
> Could we simplify testing for some types of patches? E.g. if the patch only
> touches documentation, don’t run tests, except those that involve building
> docs, if we have any of those.
I think that's a good idea to investigate, but
25.01.2019, 23:33, "Thiago Macieira" :
> On Friday, 25 January 2019 04:54:22 PST Edward Welbourne wrote:
>> we
>> fail to properly support cultures whose scripts are relegated to the
>> outer planes of Unicode - as, for example, the Chakma language's number
>> system
>
> All living languages
On Friday, 25 January 2019 13:36:04 PST Christian Ehrlicher wrote:
> Here the commit which deprecated the functions:
> https://codereview.qt-project.org/#/c/17343/
> I found one place inside QtBase which hit this problem:
> https://codereview.qt-project.org/#/c/251028/
I'm not questioning the
On Friday, 25 January 2019 13:39:49 PST Konstantin Tokarev wrote:
> > All living languages are supposed to be stored in the BMP, which means no
> > UTF-16 surrogate pairs to encode them.
>
> AFAIK all emojis are encoded with surrogate pairs
Emojis are not part of a living language. They're
50 matches
Mail list logo
