seems this time it's a rocky path to release Qt 5.12.1
Am 08.01.19 um 08:32 schrieb Jani Heikkinen:
> Hi all,
>
> Branching from '5.12' -> '5.12.1' is finally (almost) done; qtbase and
> qttools is still ongoing, there were some conflicts and so on manual merge +
> normal integration is needed
On Wednesday, 23 January 2019 07:25:44 PST Jason H wrote:
> > From: "Arnaud Clère"
> >
> > > And I don't want to add QUtf8String until SG16's char8_t gets settled.
> > > It'll probably be settled by C++20, which means we can probably work on
> > > this during Qt 6 lifetime, possibly even 6.1 or
"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 based on a tag in the commit message. We could add a
footer that marks the change risk level as in quip-5"
No sure I
> -Original Message-
> From: Development On Behalf Of
> Jedrzej Nowacki
> Sent: Wednesday, 23 January 2019 4:51 PM
> To: development@qt-project.org
> Subject: [Development] Proposal: New branch model
>
> Hi,
>
> It is time to rethink our branch model. We are approaching Qt6
>
>
>From: Development on behalf of Jedrzej
>Nowacki
> Advantages:
> - no waiting for merges, a fix can be used right away after integration
> - faster propagation of fixes targeting all branches, as there are no merges
of merges
This is pure
> From: "Arnaud Clère"
> > And I don't want to add QUtf8String until SG16's char8_t gets settled.
> > It'll probably be settled by C++20, which means we can probably work on
> > this during Qt 6 lifetime, possibly even 6.1 or 6.2.
>
> It makes sense to avoid future incompatibilities with the
On Wednesday, 23 January 2019 05:53:00 PST Edward Welbourne wrote:
> What are our chances of getting this right in Qt 6 ?
Not bad. But what you described is what SG16 is working on for std::text. So
let's not do something different from them. We can prototype it and be first,
though.
--
> -Original Message-
> From: Development On Behalf Of ekke
> Sent: Wednesday, January 23, 2019 9:45 AM
> To: development@qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
>
> seems this time it's a rocky path to release Qt 5.12.1
We're still
On 23 Jan 2019, at 17:08, Jaroslaw Kobus
mailto:jaroslaw.ko...@qt.io>> 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 based on a tag in the commit message. We
On 23 Jan 2019, at 17:20, Mitch Curtis
mailto:mitch.cur...@qt.io>> wrote:
[…snip…]
Advantages:
- no waiting for merges, a fix can be used right away after integration
Sounds nice!
- faster propagation of fixes targeting all branches, as there are no merges
of merges
- simpler for new
Hi,
It is time to rethink our branch model. We are approaching Qt6 development
and I'm worried that what we have now, will simply not scale. As you know, our
branch model is mainly(*) based on merging from stable up to development
branches. In general, it is a very good model, which make
On Wednesday, 23 January 2019 06:07:37 PST Marco Bubke wrote:
> Would it be not better to use a simple container and then functions on top
> which use a view, so we could use them with any container
If only we had a class that found boundaries in text...
On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
> I think that’s fine. What’s much worse is having a fix in 5.12 and not
> knowing how to deal with the merge conflicts into dev. That means dev might
> regress, unless whoever authored the change is willing to spend time on
>
On Wednesday, 23 January 2019 08:37:57 PST Konstantin Tokarev wrote:
> > Disadvantages:
> > - git history would be a bit wilder, "git branch --contains" would not
> > work
> > - commit messages in some branches would have kind of ugly footer as an
> >
> > effect of "cherry-pick -x"
>
>
>
>From: Martin Smith
>If you make all patches in dev and then cherrypick them back to earlier
>versions that need them, why would you ever do a merge?
At the end of the day each cherry-pick is a merge too and they can conflict
too. The conflict
Marco Bubke (23 January 2019 15:07) wrote
> Would it be not better to use a simple container and then functions on
> top which use a view, so we could use them with any container.
That sounds just fine to me.
Indeed, in separating the "Unicode text" nature from its encoding, I'm
fine with the
23.01.2019, 21:38, "Alex Blasche" :
>>
>> From: Martin Smith
>> If you make all patches in dev and then cherrypick them back to earlier
>> versions that need them, why would you ever do a merge?
>
> At the end of the day each cherry-pick is a merge too
I understand cherrypicking can result in conflicts, but surely changing to this
new model would also require changing the rules.
I would expect that for a particular patch to dev, a decision would be made to
determine which released versions the patch should be cherrypicked to.
Then the person
> On 23 Jan 2019, at 18:09, Alex Blasche wrote:
>
>
>>
>> From: Development on behalf of Jedrzej
>> Nowacki
>> Advantages:
>> - no waiting for merges, a fix can be used right away after integration
>> - faster propagation of fixes targeting all
On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> Proposal in short: let's use cherry-pick mode everywhere.
>
> 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,
Jedrzej Nowacki wrote:
>> Advantages:
>> - no waiting for merges, a fix can be used right away after
>>integration
>> - faster propagation of fixes targeting all branches, as there are
>>no merges of merges
Alex Blasche (23 January 2019 18:09)
> This is pure speculation because you
On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
>> I think that’s fine. What’s much worse is having a fix in 5.12 and not
>> knowing how to deal with the merge conflicts into dev. That means dev might
>> regress, unless whoever authored the change is willing to spend time on
>>
On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
> Jedrzej Nowacki wrote:
> >> Advantages:
> >> - no waiting for merges, a fix can be used right away after
> >>
> >>integration
> >>
> >> - faster propagation of fixes targeting all branches, as there are
> >>
> >>
On Mittwoch, 23. Januar 2019 19:43:06 CET Konstantin Tokarev wrote:
> 23.01.2019, 21:38, "Alex Blasche" :
> >>
> >> From: Martin Smith
> >> If you make all patches in dev and then cherrypick them back to earlier
> >> versions that need them, why would you
On Wed, Jan 23, 2019 at 05:40:33PM +0300, Konstantin Tokarev wrote:
> 23.01.2019, 16:55, "Edward Welbourne" :
> > All of this discussion ignores a major elephant: QString's indexing is
> > by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode
> > for a couple of decades now.
> >
>
On Wed, Jan 23, 2019 at 06:36:43PM +, Alex Blasche wrote:
> At the end of the day each cherry-pick is a merge too and they can
> conflict too. The conflict resolution process is still the same. if
> everything is conflict free then a git merge would be no more
> difficult than a cherry-pick.
All of this discussion ignores a major elephant: QString's indexing is
by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode
for a couple of decades now.
We *should* have a string type (I don't care what you call it) that acts
on strings indexed by Unicode characters, not in
I am not sure it would be a good idea because a glyph can be still composed of
more than one code points which is language dependent. Some time you want
characters, sometimes code points and sometimes glyphs etc.. Would it be not
better to use a simple container and then functions on top which
Hi
State of the CI
* Currently all OK again. We had issues with Coin update breaking the code
that re-runs flaky tests, but that was caught and fixed. Then we also had
Google changing the way Android’s SDK manager is used, so we had to create a
patch for all branches. 5.12 is at the time
> -Original Message-
> From: Thiago Macieira
>
> On Tuesday, 22 January 2019 09:01:16 PST Arnaud Clère wrote:
> > QByteArray is the official way to deal with utf8 strings but:
> > 1. This discussion shows it is not as known as it should be and I
> > argue the name does not help 2.
23.01.2019, 16:55, "Edward Welbourne" :
> All of this discussion ignores a major elephant: QString's indexing is
> by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode
> for a couple of decades now.
>
> We *should* have a string type (I don't care what you call it) that acts
>
On 23.01.19 23:15, André Pönitz wrote:
On Wed, Jan 23, 2019 at 05:40:33PM +0300, Konstantin Tokarev wrote:
23.01.2019, 16:55, "Edward Welbourne" :
All of this discussion ignores a major elephant: QString's indexing is
by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode
for a
32 matches
Mail list logo
