Re: [Development] Proposal: New branch model

Lots of good discussions around the proposal from Jedrzej. It seems like this has been inconclusive for the moment. Both cherry-picking and the current model have it’s advantages and disadvantages. One major concern was that we’d overload especially qtbase/dev integrations and this would lead

Re: [Development] Proposal: New branch model

El dom., 10 feb. 2019 05:44, Sune Vuorela escribió: [snip] I'm mostly a casual contributor, mostly dealing with fixes to bugs found > in specific releases. I'm doing my fixes in those releases. Because > that's where I need them. If I could just then push it and more or less > forget about it,

Re: [Development] Proposal: New branch model

On 2019-01-25, 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 branch. I'm mostly a

Re: [Development] Proposal: New branch model

On fredag 25. januar 2019 21:40:07 CET Thiago Macieira wrote: > 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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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 >

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

> -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:3

Re: [Development] Proposal: New branch model

>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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

>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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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 >

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

> 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,

Re: [Development] Proposal: New branch model

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 > >

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

> 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

Re: [Development] Proposal: New branch model

er Cc: Qt development mailing list Subject: Re: [Development] Proposal: New branch model 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 i

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

ers, Robert > > Another advantage is that this would pave the road towards a system where CI > testing happens before human review, so we can in the longer term avoid > duplicated review/approval work. > > Cheers, > Lars > > > > > Simon > ________

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

> 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

Re: [Development] Proposal: New branch model

l work. > > Cheers, > Lars > >> >> >> >> Simon >> From: Lars Knoll >> Sent: Friday, January 25, 2019 9:05:45 AM >> To: Ville Voutilainen >> Cc: Simon Hausmann; Qt development mailing list >> Subject: Re: [Development] Proposal: New

Re: [Development] Proposal: New branch model

l Sent: Friday, January 25, 2019 9:05:45 AM To: Ville Voutilainen Cc: Simon Hausmann; Qt development mailing list Subject: Re: [Development] Proposal: New branch model > On 24 Jan 2019, at 22:29, Ville Voutilainen > mailto:ville.voutilai...@gmail.com>> wrote: > > On Thu, 24

Re: [Development] Proposal: New branch model

*From:* Kari Oikarinen > *Sent:* Friday, January 25, 2019 10:41:21 AM > *To:* Simon Hausmann; Lars Knoll; Ville Voutilainen > *Cc:* Qt development mailing list > *Subject:* Re: [Development] Proposal: New branch model > How would the CI load not change? Rather than one merge bringing

Re: [Development] Proposal: New branch model

Hausmann; Lars Knoll; Ville Voutilainen Cc: Qt development mailing list Subject: Re: [Development] Proposal: New branch model 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

Re: [Development] Proposal: New branch model

ot change for anybody working in dev. > > > > > Simon > > > *From:* Lars Knoll > *Sent:* Friday, January 25, 2019 9:05:45 AM > *To:* Ville Voutilainen > *Cc:* Simon Hausmann; Qt developmen

Re: [Development] Proposal: New branch model

. Simon From: Lars Knoll Sent: Friday, January 25, 2019 9:05:45 AM To: Ville Voutilainen Cc: Simon Hausmann; Qt development mailing list Subject: Re: [Development] Proposal: New branch model > On 24 Jan 2019, at 22:29, Ville Voutilainen > wrote: > >

Re: [Development] Proposal: New branch model

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

Re: [Development] Proposal: New branch model

ent: Friday, January 25, 2019 9:25:16 AM To: Allan Sandfeld Jensen; Jedrzej Nowacki Cc: development@qt-project.org Subject: Re: [Development] Proposal: New branch model I'm somewhat attracted to the proposed model, in conjunction with automation and by treating Qt6 differently. However Allan's l

Re: [Development] Proposal: New branch model

that quite a bit of tooling needs to be developed first anyway? Simon From: Development on behalf of Allan Sandfeld Jensen Sent: Thursday, January 24, 2019 1:33:28 PM To: Jedrzej Nowacki Cc: development@qt-project.org Subject: Re: [Development] Proposal: New

Re: [Development] Proposal: New branch model

To: Simon Hausmann Cc: Jedrzej Nowacki; development@qt-project.org Subject: 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

Re: [Development] Proposal: New branch model

> 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

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

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

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

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

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

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

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:

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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) >

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 > > > >

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

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

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

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

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

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

>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

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

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

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

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 >>>

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

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

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

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

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

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

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

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

  1   2   >