Re: [Development] Qt6: Adding UTF-8 storage support to QString

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 encoding (e.g. isUtf16()) and access raw data How o

Re: [Development] Qt6: Adding UTF-8 storage support to QString

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 in a private header. But we may want to make it iterate over graph

Re: [Development] Proposal: New branch model

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 doesn’t help in this setup I think. Completely seriously, without any prefe

Re: [Development] Proposal: New branch model

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 complications. Engineers prefer what's known, from experience, to work over th

Re: [Development] Proposal: New branch model

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 doesn’t help in this setup I think. Simon > On 24. Jan 2019, at 15:28, Jedrzej Nowacki wrote: > > Dnia środa, 23 stycznia 2019 23:05:17

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 13:33:28 CET Allan Sandfeld Jensen pisze: > On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote: > > Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze: > > > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote: > > > >

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 14:23:21 CET Kari Oikarinen pisze: > We're also using cherry-picking ourselves in LTS branches. At least older > ones, 5.12 is not at that mode yet. As far as I know it has been working > well. > Since the problems with cherry-picking come up as the changes pile up

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 23:05:17 CET Allan Sandfeld Jensen pisze: > More than that. Once you have had cherry-pick only for a while git will be > unable to find useful common ancestors for the changes, and will be unable > to do smart three-way merging of cherry-picks, increasing the number of

Re: [Development] Proposal: New branch model (part: new contributors)

On Thu, 24 Jan 2019 at 16:14, Konstantin Tokarev wrote: > > > > 24.01.2019, 17:09, "Ville Voutilainen" : > > With the proposed model I push into trunk like in every other project. > > Why every other? Quite a few projects have different policies, e.g. in > some of them master is always in more-or-

Re: [Development] Proposal: New branch model

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 we don't, because once 5.x+1 is >> created, 5.x is closed. > > Not quite: once

Re: [Development] Proposal: New branch model

24.01.2019, 17:13, "Jedrzej Nowacki" : > Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze: >>  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 merg

Re: [Development] Proposal: New branch model

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 we don't, because once 5.x+1 is > created, 5.x is closed. Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed (unless

Re: [Development] Proposal: New branch model

On Thu, 24 Jan 2019 at 15:39, Shawn Rutledge wrote: > > > > > On 24 Jan 2019, at 14:15, Jedrzej Nowacki wrote: > > > > Typical use case I have with bug fixing in dev is when I develop a feature > > and > > I see let's say a memory leak in the code that I'm modifying or somewhere > > around. With

Re: [Development] Proposal: New branch model (part: new contributors)

24.01.2019, 17:09, "Ville Voutilainen" : > With the proposed model I push into trunk like in every other project. Why every other? Quite a few projects have different policies, e.g. in some of them master is always in more-or-less ready for release state and new changes go to staging branch like

Re: [Development] Proposal: New branch model (part: new contributors)

Dnia środa, 23 stycznia 2019 18:09:31 CET Alex Blasche pisze: > > - simpler for new contributors, always push to dev > > Really? Me being the new guy wanting to fix a bug in 5.12 need to magically > know that I have to push to dev and know about a magic cherry-pick logic > and a magic tag in the c

Re: [Development] Proposal: New branch model

On Thu, 24 Jan 2019 at 15:47, Edward Welbourne wrote: > > Allan Sandfeld Jensen (24 January 2019 14:35) > > We can't integrate multiple changes to the same branch in parellel. > > I was under the impression that was exactly what we do. > > When I press Stage, my change gets cherry-picked to a litt

Re: [Development] Proposal: New branch model

On 24.1.2019 15.15, Jedrzej Nowacki wrote: > Last, but not least. The release branches are already in cherry-pick mode, so > again it is not different, amount of conflicts is the same, true one needs to > solve them earlier, but on the other hand you can prepare the conflict > resolution in paral

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze: > 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 >

Re: [Development] Proposal: New branch model (part: new contributors)

On Thu, 24 Jan 2019 at 15:56, Jedrzej Nowacki wrote: > > Dnia środa, 23 stycznia 2019 18:09:31 CET Alex Blasche pisze: > > > - simpler for new contributors, always push to dev > > > > Really? Me being the new guy wanting to fix a bug in 5.12 need to magically > > know that I have to push to dev an

Re: [Development] Proposal: New branch model

Allan Sandfeld Jensen (24 January 2019 14:35) > We can't integrate multiple changes to the same branch in parellel. I was under the impression that was exactly what we do. When I press Stage, my change gets cherry-picked to a little branch that gerrit is building, along with (i.e. in parallel wit

Re: [Development] Proposal: New branch model

> On 24 Jan 2019, at 14:15, Jedrzej Nowacki wrote: > > Typical use case I have with bug fixing in dev is when I develop a feature > and > I see let's say a memory leak in the code that I'm modifying or somewhere > around. With the merge model I have four options now: > 1. Pretend that I have

Re: [Development] Proposal: New branch model

On Donnerstag, 24. Januar 2019 14:31:16 CET Jedrzej Nowacki wrote: > Dnia czwartek, 24 stycznia 2019 10:24:57 CET Allan Sandfeld Jensen pisze: > > > On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote: > > > > > More people working and building against dev helps keep dev more stab

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 10:24:57 CET Allan Sandfeld Jensen pisze: > On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote: > > More people working and building against dev helps keep dev more stable > > (by > > virtue of discovering breakage sooner), and the proposal encourage

Re: [Development] Proposal: New branch model

> On 24 Jan 2019, at 14:10, Edward Welbourne wrote: > > Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze: >>> My concern is about "cherry-pick" a series of changes for a big >>> feature, especially during the period to have "dev" branches for both >>> 5 and 6. I don't have solution f

Re: [Development] Proposal: New branch model

On 24.1.2019 15.10, Edward Welbourne wrote: > Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze: >>> My concern is about "cherry-pick" a series of changes for a big >>> feature, especially during the period to have "dev" branches for both >>> 5 and 6. I don't have solution for this issue

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 22:09:30 CET Allan Sandfeld Jensen pisze: > 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 > > >> > > >

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze: >> My concern is about "cherry-pick" a series of changes for a big >> feature, especially during the period to have "dev" branches for both >> 5 and 6. I don't have solution for this issue yet. Jedrzej Nowacki (24 January 2019 11:53) > M

Re: [Development] Qt6: Adding UTF-8 storage support to QString

24.01.2019, 10:34, "Olivier Goffart" : > 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

Re: [Development] Proposal: New branch model

On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote: > Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze: > > > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote: > > > > > Proposal in short: let's use cherry-pick mode everywhere. > > > > > >

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze: > 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 > > > > che

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

Am 23.01.19 um 17:03 schrieb Kai Koehne: >> -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 i

Re: [Development] Qt6: Adding UTF-8 storage support to QString

> - Introduce some iterator that iterates over unicode code points. QStringIterator > We *should* have a string type (I don't care what you call it) that acts > on strings indexed by Unicode characters, not in terms of a > representation. Whether that string type internally uses UTF-16 or > UT

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 11:24:41 CET Vitaly Fanaskov pisze: > > Why not X instead? > > -- > > > > - GitFlow, GitHub <= both are based on feature branches, that doesn't work > > well with gerrit. > > So, the only problem here is gerrit (aside from personal preferences and >

Re: [Development] Proposal: New branch model

Good point. Also thinking this way every time need to deal with Gerrit. Any chance to replace it to something more modern and convenient and less time wasting like GitLab, etc? --  Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 24.01.2019, 12:28, "Vitaly Fanasko

Re: [Development] Proposal: New branch model

Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze: > My concern is about "cherry-pick" a series of changes for a big > feature, especially during the period to have "dev" branches for both > 5 and 6. I don't have solution for this issue yet. My assumption is that bot would cherry-pick th

Re: [Development] Proposal: New branch model

On Wed, 23 Jan 2019 at 17:53, 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, would be taken b

Re: [Development] Proposal: New branch model

On 23.1.2019 17.51, Jedrzej Nowacki wrote: >>Can we use annotate instead of cherry-pick -x? >>-- >> >>No, but we should use it in addition. Annotations are mutable, >> therefore are not 100% trust worthy. If we have both, we could >> validate

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 17:37:57 CET Konstantin Tokarev pisze: > Note that backporting changes from dev should also be a full-time job for > someone, otherwise amount of fixes going to stable branches will likely > drop Yes, depending who you ask it is good or bad. It means that only fixes th

Re: [Development] Proposal: New branch model

Dnia środa, 23 stycznia 2019 18:49:46 CET Thiago Macieira pisze: > 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

Re: [Development] Proposal: New branch model

On 23.1.2019 17.51, Jedrzej Nowacki wrote: >Can we use annotate instead of cherry-pick -x? >-- > >No, but we should use it in addition. Annotations are mutable, therefore > are > not 100% trust worthy. If we have both, we could validate an

Re: [Development] Proposal: New branch model

>Why not X instead? >-- > >- GitFlow, GitHub <= both are based on feature branches, that doesn't work > well with gerrit. So, the only problem here is gerrit (aside from personal preferences and habits of course). The question is shouldn't we abandon gerrit as this too

Re: [Development] Proposal: New branch model

On 24.1.2019 11.49, Edward Welbourne wrote: > Olivier Goffart (24 January 2019 08:03) >> Let's start by looking at the "problem" > > Always a good place to start. > > On 23.01.19 16:51, Jedrzej Nowacki wrote: >>> My impression is that the current model works great for a single >>> release b

Re: [Development] Proposal: New branch model

On 24.1.2019 11.13, Edward Welbourne wrote: >> A cherry-pick takes the diff involved in one commit and patches >> another check-out with it. A merge uses the digraph of commits in >> sophisticated ways; a cherry-pick does not. Kari Oikarinen (24 January 2019 10:33) > Quoting man page for git-cher

Re: [Development] Proposal: New branch model

On 24.1.2019 11.11, Volker Hilsheimer wrote: > > >> On 23 Jan 2019, at 22:09, Allan Sandfeld Jensen > > wrote: >> >> On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote: >>> Jedrzej Nowacki wrote: > Advantages: > - no waiting for merges, a fix can

Re: [Development] Proposal: New branch model

Olivier Goffart (24 January 2019 08:03) > Let's start by looking at the "problem" Always a good place to start. On 23.01.19 16:51, Jedrzej Nowacki wrote: >>My impression is that the current model works great for a single >> release branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13,

Re: [Development] Proposal: New branch model

> 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 based on a tag in the commit message. We could add a >>> f

Re: [Development] Proposal: New branch model

On Thu, Jan 24, 2019 at 09:13:32AM +, Edward Welbourne wrote: > A cherry-pick takes the diff involved in one commit and patches another > check-out with it. A merge uses the digraph of commits in sophisticated > ways; a cherry-pick does not. > uhhh, actually, it does. cherry-pick even has the

Re: [Development] Proposal: New branch model

On Donnerstag, 24. Januar 2019 10:13:32 CET Edward Welbourne wrote: > OK, now you're just engaging in ill-informed FUD. > Cherry-picks do not involve any three-way anything. > You clearly do not understand the difference between merging and > cherry-picking. > > A cherry-pick takes the diff involv

Re: [Development] Proposal: New branch model

On 24.1.2019 11.13, Edward Welbourne wrote: > 23.01.2019, 21:38, "Alex Blasche" : At the end of the day each cherry-pick is a merge too > > Merges and cherry-picks have a certain amount in common, but they are > not the same thing at all. > and they can conflict too. The conflict reso

Re: [Development] Proposal: New branch model

On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote: > More people working and building against dev helps keep dev more stable (by > virtue of discovering breakage sooner), and the proposal encourages more > people to work on dev. That can be a good thing. No, it will overload th

Re: [Development] Proposal: New branch model

> 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 how the proposed model reduce the amount of conflicts.

Re: [Development] Proposal: New branch model

23.01.2019, 21:38, "Alex Blasche" : >>> At the end of the day each cherry-pick is a merge too Merges and cherry-picks have a certain amount in common, but they are not the same thing at all. >>> and they can conflict too. The conflict resolution process is still >>> the same. if everything is con

Re: [Development] Proposal: New branch model

On 23 Jan 2019, at 22:09, Allan Sandfeld Jensen mailto:k...@carewolf.com>> wrote: 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 target

Re: [Development] Proposal: New branch model

From: Volker Hilsheimer Sent: Wednesday, January 23, 2019 5:25 PM To: Jaroslaw Kobus Cc: Jedrzej Nowacki; development@qt-project.org Subject: Re: [Development] Proposal: New branch model On 23 Jan 2019, at 17:08, Jaroslaw Kobus mailto:jaroslaw.ko...@qt.io

Re: [Development] Proposal: New branch model

Lots of talks happened already on this thread. I would like to think old model as "merge" model VS new model as "cherry-pick" model. In the old "merge" model, normally we will drop a branch out to cherry-pick mode after having more than 3 branches and try to have 2 branches(change LTS branch to c