Re: [Development] Archiving is working
> -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 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 messages, on the bugtracker, and so on. > Breaking them is a big no-no-no. Another +1. I don't want my commit messages to become useless because of broken mailing list archive links. I'm pretty sure I also linked to a mailing list thread when I did a bulk Qt 4 jira task cleanup, so if that link is now broken it's broken in hundreds of comments. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Jannis Völker for Approver
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 would like to nominate Jannis Völker for approvership. He has been an active contributor to Qt OpcUA mostly since end of 2017. He also has been actively taking care on JIRA, bug fixing and bringing the whole module forward. If you're curious, here is a list of his changes: https://codereview.qt-project.org/#/q/owner:%22Jannis+V%25C3%25B6lker%22,n,z Reviews: https://codereview.qt-project.org/#/q/reviewer:%22Jannis+V%25C3%25B6lker%22,n,z BR, Maurice ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 tested together. This in >> turn increasing the risk of rejection of all changes because of one >> bad change in the set. So the current system doesn’t scale and >> basically rate limits the amount of changes going into a branch (or >> worse, we end up getting traffic jams where the actual rate actually >> goes down to zero). My working guess at what the present system does is that it piles up a staging branch with everything that gets staged while an integration is running; when one integration completes (with maybe some modest delay if the staging branch is sort), the staging branch gets its turn to attempt to integrate (possibly via a rebase onto a freshly-integrated branch). I hope someone who knows the actual process can describe it in this thread. If that's reasonably close to true, the we shall indeed get many commits piling up in each staging branch, increasing the likelihood of failure in the integration attempt. We could mitigate that in various ways by tweaking the process. In particular, we could cap the length of staging branches (perhaps with a bit of flexibility to let in commits with the same owner as some already in the branch, so that groups of related changes don't get split up); once a staging branch hits the cap, we start a fresh staging branch. This gives us a queue of staging branches, rather than just one, each waiting to be integrated. >> To me this means we need to seriously rethink that part of our CI >> system, and ideally test changes (or patch series) individually and >> in parallel. So maybe we should adjust our CI system that way: >> >> * test changes (or patch series) individually >> * If they pass CI merge or cherry-pick them into the branch >> * reject only if the merge/cherry-pick gives conflicts We could equally run several integrations in parallel and select one of those that succeed (probably the one that entered the staging queue earliest) to be the new tip; all others that succeed, plus any new staging branches grown in the interval, get rebased onto that and tested in parallel again. That'll be "wasteful" of Coin resources in so far as some branches pass repeatedly before getting accepted, but it'll avoid the small risk you describe below. The "speculative" integrations being run in parallel with the "will win if several succeed" one make the most of Coin having the capacity to run several in parallel - assuming it does. >> 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 happens the repo will be blocked for further >> testing until someone submits a fix or reverts an offending change, >> which is acceptable. When those events happen, they're going to gum up the whole works until they're sorted out; they require manual intervention, Which Is Bad. Robert Loehning (25 January 2019 17:49) replied > Could that be solved by testing the combinations of changes again? > > * test changes (or patch series) individually > * If they pass CI merge or cherry-pick them into some local branch > * reject if the merge/cherry-pick gives conflicts > * when time period x has passed or the local branch contains y changes, > test the local branch >good: push the local branch to the public one >bad: repeat step four with a subset of the changes it had before > > Assuming that y is significantly greater than 1, the added overhead for > one more test run seems relatively small to me. IIUC, you're describing a two-stage integration process; test many staging branches in parallel; accumulate successes; combine those and re-test; if good, keep. There shall be new staging branches coming out of the sausage machine while the earlier composite is going. We have to work out what to do with those. If the composite fails, these fresh successes can be combined and tested just as the earlier one was; but, if the earlier composite passes, we need to rebase the integrations that have passed while it was tested. However, all these have passed previously, so we have fair confidence in them; so we can combine them all together on the prior composite and set about testing this as a second-stage composite integration. So I think that has a good chance of working well. A note on merge vs rebase here: when merging several branches that have passed first-integration, a conflict excludes a whole branch, though it's probably caused by one or few of the commits in the branch; whereas rebasing lets you detect which individual commits cause the conflicts, so that only these get left out. It also gives you a linea
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 because >>> higher rates imply that more changes are tested together. This in >>> turn increasing the risk of rejection of all changes because of one >>> bad change in the set. So the current system doesn’t scale and >>> basically rate limits the amount of changes going into a branch (or >>> worse, we end up getting traffic jams where the actual rate actually >>> goes down to zero). > > My working guess at what the present system does is that it piles up a > staging branch with everything that gets staged while an integration is > running; when one integration completes (with maybe some modest delay if > the staging branch is sort), the staging branch gets its turn to attempt > to integrate (possibly via a rebase onto a freshly-integrated branch). > I hope someone who knows the actual process can describe it in this > thread. > > If that's reasonably close to true, the we shall indeed get many commits > piling up in each staging branch, increasing the likelihood of failure > in the integration attempt. We could mitigate that in various ways by > tweaking the process. > > In particular, we could cap the length of staging branches (perhaps with > a bit of flexibility to let in commits with the same owner as some > already in the branch, so that groups of related changes don't get split > up); once a staging branch hits the cap, we start a fresh staging > branch. This gives us a queue of staging branches, rather than just > one, each waiting to be integrated. > >>> To me this means we need to seriously rethink that part of our CI >>> system, and ideally test changes (or patch series) individually and >>> in parallel. So maybe we should adjust our CI system that way: >>> >>> * test changes (or patch series) individually >>> * If they pass CI merge or cherry-pick them into the branch >>> * reject only if the merge/cherry-pick gives conflicts > > We could equally run several integrations in parallel and select one of > those that succeed (probably the one that entered the staging queue > earliest) to be the new tip; all others that succeed, plus any new > staging branches grown in the interval, get rebased onto that and tested > in parallel again. That'll be "wasteful" of Coin resources in so far as > some branches pass repeatedly before getting accepted, but it'll avoid > the small risk you describe below. The "speculative" integrations being > run in parallel with the "will win if several succeed" one make the most > of Coin having the capacity to run several in parallel - assuming it does. > >>> 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 happens the repo will be blocked for further >>> testing until someone submits a fix or reverts an offending change, >>> which is acceptable. > > When those events happen, they're going to gum up the whole works until > they're sorted out; they require manual intervention, Which Is Bad. > > Robert Loehning (25 January 2019 17:49) replied >> Could that be solved by testing the combinations of changes again? >> >> * test changes (or patch series) individually >> * If they pass CI merge or cherry-pick them into some local branch >> * reject if the merge/cherry-pick gives conflicts >> * when time period x has passed or the local branch contains y changes, >> test the local branch >> good: push the local branch to the public one >> bad: repeat step four with a subset of the changes it had before >> >> Assuming that y is significantly greater than 1, the added overhead for >> one more test run seems relatively small to me. > > IIUC, you're describing a two-stage integration process; test many > staging branches in parallel; accumulate successes; combine those and > re-test; if good, keep. There shall be new staging branches coming out > of the sausage machine while the earlier composite is going. We have to > work out what to do with those. If the composite fails, these fresh > successes can be combined and tested just as the earlier one was; but, > if the earlier composite passes, we need to rebase the integrations that > have passed while it was tested. However, all these have passed > previously, so we have fair confidence in them; so we can combine them > all together on the prior composite and set about testing this as a > second-stage composite integration. So I think that has a good chance > of working well. > > A note on merge vs rebase here: when merging several branches that have > passed first-integration, a conflict excludes a whole branch, though > it's pro
Re: [Development] Archiving is working
> 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 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 messages, on the bugtracker, and so on. >> Breaking them is a big no-no-no. > > Another +1. I don't want my commit messages to become useless because of > broken mailing list archive links. I'm pretty sure I also linked to a mailing > list thread when I did a bulk Qt 4 jira task cleanup, so if that link is now > broken it's broken in hundreds of comments. +1 from me too If the archive can’t be regenerated with the same numbers, aren’t there backups somewhere that can be restored? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 how the proposed model reduce the amount of conflicts. >> If the "one person" is the problem, then nothing prevents you to assign more >> people to the job. One easy way is already to share the different modules >> (repositories). But with some cooperation it is also possible to share the >> work accross directories, or by number of commits. One can also be pragmatic >> and revert most problematic commit (that fails tests) in dev or stable, then >> let the author work at it again. > > Having to wait for someone else to trigger the merge and resolve the various > conflicts before I can continue to base my work on dev on a fix that I > already made in 5.12 breaks flow. Distributing this work to more people > doesn’t solve the problem. > > 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 > for cleaning up the mess my change might have caused. The current model > doesn’t give me any of that beyond the initial merge. 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. Cheers, Robert -- Robert Löhning, Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: New branch model
>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 there a maintainer for each LTS version?) would decide whether the change should be cherrypicked into an LTS version. martin From: Development on behalf of Robert Loehning Sent: Monday, January 28, 2019 1:27:20 PM To: Volker Hilsheimer 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 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. >> If the "one person" is the problem, then nothing prevents you to assign more >> people to the job. One easy way is already to share the different modules >> (repositories). But with some cooperation it is also possible to share the >> work accross directories, or by number of commits. One can also be pragmatic >> and revert most problematic commit (that fails tests) in dev or stable, then >> let the author work at it again. > > Having to wait for someone else to trigger the merge and resolve the various > conflicts before I can continue to base my work on dev on a fix that I > already made in 5.12 breaks flow. Distributing this work to more people > doesn’t solve the problem. > > 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 > for cleaning up the mess my change might have caused. The current model > doesn’t give me any of that beyond the initial merge. 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. Cheers, Robert -- Robert Löhning, Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 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. If the "one person" is the problem, then nothing prevents you to assign more people to the job. One easy way is already to share the different modules (repositories). But with some cooperation it is also possible to share the work accross directories, or by number of commits. One can also be pragmatic and revert most problematic commit (that fails tests) in dev or stable, then let the author work at it again. >>> >>> Having to wait for someone else to trigger the merge and resolve the >>> various conflicts before I can continue to base my work on dev on a fix >>> that I already made in 5.12 breaks flow. Distributing this work to more >>> people doesn’t solve the problem. >>> >>> 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 for cleaning up the mess my change might have caused. The >>> current model doesn’t give me any of that beyond the initial merge. >> >> 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 there a > maintainer for each LTS version?) would decide whether the change should be > cherrypicked into an LTS version. > > martin 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 should be the first branch. 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 different cases that are not covered by CI - isn’t that valuable? Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 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. > If the "one person" is the problem, then nothing prevents you to assign > more people to the job. One easy way is already to share the different > modules (repositories). But with some cooperation it is also possible to > share the work accross directories, or by number of commits. One can also > be pragmatic and revert most problematic commit (that fails tests) in dev > or stable, then let the author work at it again. Having to wait for someone else to trigger the merge and resolve the various conflicts before I can continue to base my work on dev on a fix that I already made in 5.12 breaks flow. Distributing this work to more people doesn’t solve the problem. 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 for cleaning up the mess my change might have caused. The current model doesn’t give me any of that beyond the initial merge. >>> >>> 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 there a >> maintainer for each LTS version?) would decide whether the change should be >> cherrypicked into an LTS version. >> >> martin > > > 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 should be the first branch. In the new model, dev should always be the first branch. Would we then have some changes for which picking and resolving conflicts is expected to be done by the author, some for which it is expected to be done by the maintainers and a gray area between those? > 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 > different cases that are not covered by CI - isn’t that valuable? > > > Volker > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 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 we have a pressing reason to release another 5.x.y). > > So, in the interval between 5.x+1 branching and releasing, > > we have three branches. > > > Right, so typically we indeed have two stable branches open. Thanks for > correcting me. > > > > > > > >> But 5.12 is an LTS version, so it will still stay open. > > > > > > Indeed. > > > > > >> But at what point (under current process) would be switch it to > >> cherry-pick only mode? I don't remember when it happened for 5.9. It > >> could be when 5.13 is created and then there would be no release blocked > >> by waiting for a merge.> > > > > We switch to cherry-picking into 5.12 when 5.14 is created. > > See QUIP-5, > > * https://quips-qt-io.herokuapp.com/quip-0005.html > > > > So creation of 5.14 switches our merge pattern from 5.12->5.13->dev > > to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13. > > Again, we could of course change that. > > > Yes, but I was attempting to describe the current approach and messed it > up. > -- > Kari Well, you are still right about the fact that 5.x.z is not in cherry-pick mode always. How it can happen that people involved in the process aren't always correct about branching model. That is simply too complex to follow. Btw. it also may add one merge to all merges count I mentioned before. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 > > the latest codebase? Perhaps the issue has been fixed already, just > > without the author considering it relevant for 5.12 (perhaps for good > > reasons). > Why would somebody who maintains a project on Qt5 but made the decision > to not migrate it to Qt6 care about fixing the latter? > > Cheers, > Robert Project that is not being updated is not maintained. Not maintained projects should not take part of the mainstream. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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, 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. >> If the "one person" is the problem, then nothing prevents you to assign >> more people to the job. One easy way is already to share the different >> modules (repositories). But with some cooperation it is also possible to >> share the work accross directories, or by number of commits. One can >> also be pragmatic and revert most problematic commit (that fails tests) >> in dev or stable, then let the author work at it again. > > Having to wait for someone else to trigger the merge and resolve the > various conflicts before I can continue to base my work on dev on a fix > that I already made in 5.12 breaks flow. Distributing this work to more > people doesn’t solve the problem. > > 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 for cleaning up the mess my change might have caused. The > current model doesn’t give me any of that beyond the initial merge. 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 there a >>> maintainer for each LTS version?) would decide whether the change should be >>> cherrypicked into an LTS version. >>> >>> martin >> >> >> 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 should be the first branch. > > In the new model, dev should always be the first branch. Would we then > have some changes for which picking and resolving conflicts is expected > to be done by the author, some for which it is expected to be done by > the maintainers and a gray area between those? I think “it depends”, and it’ll be a matter of negotiation. The worst case scenario in case of cherry-pick-conflict is “we couldn’t agree on whether it should go into stable, or we couldn’t find anyone to port it back, so it’ll only be in the next minor release”. That’s not such a terrible "worst case”, I think. Making the merge into dev independent of that discussion at least keeps things moving forward. If then the author doesn’t want to spend time on backporting and conflict resolving, but there are lots of users and customers asking for the fix, then that’s a matter of finding someone else to pick up the challenge. Of course, doing it like what Jędrek (IIRC) reported from the Python community and leaving it to the maintainers to take things down into stable branches is one way. Then maintainers have control over the order and timing, and can perhaps avoid a lot of mess that way. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 complications. Engineers prefer > > what's known, from experience, to work over things that sound like they > > might. OTOH, as Ville points out, other projects do use cherry-picking; > > so perhaps we need more information from such projects, > > I have seen this implemented, similar to what Jedrek proposed, but the > decision where to cherry pick is in JIRA, not via git annotations/marks. > > This requires the Release Manager to keep an eye on which changes have > not being propagated to all branches, though. > > fully automated process, the fix is pushed to the oldest branch (5.12) > and then propagated to newer versions (5.13, dev, etc). Change is > automatically cherry-picked, updated the commit message, uploaded to > gerrit, automatic Code-Review+2, automatic stage, automatically merged > if CI passes. > > propagation rate failure is around 20% of, mostly due to: > - merge conflicts (will happen, for sure) > -- genuine merge conflicts > -- change was already cherry-picked manually > -- dependencies missing > - ci failures > -- mostly due to infrastructure issues > -- ci does not know how to handle dependencies > > advantages: > - when it works, everybody is happy > - pass rate is very high (around 80%) > - one can run git-cherry-pick -n and add additional info in the commit > message > - can be tuned up to exclude some changes from being propagated (the > bot, not git-cherry-pick itself) > > 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 well? why don't you do merges instead and leave alone? > [true story :-)] > - change can pass the CI and found to be problematic later on > -- oh, I need to fix my change in 5 branches now? [Gerrit 2.14 has a > cherry-pick button in the UI now, so this is not a problem with that > version] > - automated cherry-pick process/bot/script has to be maintained > -- one change not merged might lead to lots of changes to fail with > merge conflicts, staying open in gerrit forever > -- hey, can you add intelligence to the bot so it know how to merge the > open changes once the dependency is merged? > -- hey, can you add intelligence to the bot so it can cherry-pick them > in the right order?) > - yes, git-cherry-pick does weird things. I have seen it cherry-picking > the same change twice without problems (same line twice in the file, I > think I was an include guard that compiled but behaved weirdly, or similar) > > my 2€ Thank you for the story, do I get it correctly that the most of problems are social and global flakiness of the system? Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 merging > to different branches, that way we CAN have multiple integrations running > in parallel. Well, I can use more resources. We can build on stronger machines CPU limits are quite arbitrary. We could build tests during build phase (it means more CPU power, Aapo is currently pushing the task forward). In the end we could execute tests on multiple machines (it is an old idea, that was just down- prioritized). /side note: The fact that we do not run multiple integration in parallel for one branch is super annoying to me, it is just waste of time, we should change it. As far I know we are doing it only to avoid potential breakages caused by two concurrent change, in my opinion cost / gain ratio is terrible. Again that is another discussion. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 checking whether the issue is still present in >>> the latest codebase? Perhaps the issue has been fixed already, just >>> without the author considering it relevant for 5.12 (perhaps for good >>> reasons). >> Why would somebody who maintains a project on Qt5 but made the decision >> to not migrate it to Qt6 care about fixing the latter? >> >> Cheers, >> Robert > > Project that is not being updated is not maintained. Not maintained projects > should not take part of the mainstream. > > Cheers, >Jędrek > > 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 5. They even provide this fix, but why would they care about making it work in Qt 6? Cheers, Robert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 happens the repo will be blocked for further testing until someone > submits a fix or reverts an offending change, which is acceptable. > > 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. Yes, yes, yes, pretty please :-) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Good idea to update Windows 10 to 1809 - Redstone 5?
> -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 things to the latest. But > regarding Windows 10 I was told we shouldn't perhaps do that, because Qt's > code will select and different path depending on the API levels available from > Windows. Qt WebEngine in Qt 5.13 will require a newer version of Windows 10, so it's high time to update Windows 10 in our CI. If we really start depending on stuff from a newer Windows 10 SDK, I guess we'd notice when testing on Windows 7, which we AFAIK test for before a release. My 2 cents, Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 > > submit documentation-only changes to QtBase, and they often get tested > > alone, with no other changes. They still get rejected multiple times > > because test X fails this time and test Y fails next time, despite the > > fact that my change only fixes typos in the qdoc comments. Sometimes > > there is a compiler failure too, which is not caused by the change. > > 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. (Even building the code is dubious in that > case, as long as the bot that decides that it’s a doc-only patch actually > verifies that the only changes are inside comments.) If it only touches > widgets, some time-consuming and failure-prone tests like network tests > could be skipped. And so on. Sure, please implement it :-). It has to be maintained on the build system level, so one can start already. CI can provide some magic parameters to the build system and then the build system can use whatever heuristic are needed when running "make check". I wouldn't mind that option even for local development. This is out of scope for branch model discussion, for my taste :-) Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 into 5.12 and for whatever reason there are issues with > that. > > There is a risk that the bug will not be fixed in the next (or any) 5.12 > release even though it already is fixed in 5.9. Granted, it will be fixed > in 5.13 again. This is also not ideal and requires release management to > keep track of these changes to avoid it. (Some of this risk exists also for > 5.12.x branch vs 5.12 branch, if we directly pick from dev to 5.12.x) Yes, It may happen, but as you said in the infinity it will be fixed. Tracking should be quite easy, it is just a gerrit query; give me all 1 month old, open changes for branch 5.12. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 for cleaning up the mess my change might have caused. The current model doesn’t give me any of that beyond the initial merge. On 28 Jan 2019, at 13:27, Robert Loehning wrote: >>> 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. On 28 Jan 2019, at 13:36, Martin Smith 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 be cherrypicked into an LTS version. Some will do as you expect. Others will do otherwise. A client project, using Qt, that's opted to use our last LTS will, when it contributes fixes to Qt that have been prompted by their need to fix a problem Qt is causing for them, will most likely contribute their fix targeting the LTS - they're upstreaming the fix they're using locally, in the hopes that they'll one day stop needing to maintain that fix themselves by patching their Qt sources. They won't know or care about dev. We can, of course, ask them to deliver the fix via dev, which may require re-working it; but they'll want to know it's going to make its way to the LTS, because that's what they care about. 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 should be the first > branch. It (mostly) suits *our* needs best for everything to land in dev; but not all potential contributors have the same priorities as us. > 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 different cases that are not covered by CI - isn’t that > valuable? Yes, that is valuable; so is the stability of stable branches. Actually scrutinising each bug-fix that's going into a stable branch in the context of that stable branch - rather than in the context of a dev branch, from which it's cherry-picked with less scrutiny into the stable one - makes it less likely that we'll break the stable branch. Users surely have stronger expectations of stability for stable branches than for cutting-edge first releases of a later minor version. So breakage in dev (caused by things merged up to it) is less harmful than breakage in stable (caused by things cherry-picked down to it). Which of these valuable things do we prize more highly ? Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 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 we have a pressing reason to release another 5.x.y). >>> So, in the interval between 5.x+1 branching and releasing, >>> we have three branches. >> >> >> Right, so typically we indeed have two stable branches open. Thanks for >> correcting me. >> >> >>> >>> But 5.12 is an LTS version, so it will still stay open. >>> >>> >>> Indeed. >>> >>> But at what point (under current process) would be switch it to cherry-pick only > mode? I don't remember when it happened for 5.9. It could be when 5.13 is created and then there would be no release blocked by waiting for a merge.> >>> >>> We switch to cherry-picking into 5.12 when 5.14 is created. >>> See QUIP-5, >>> * https://quips-qt-io.herokuapp.com/quip-0005.html >>> >>> So creation of 5.14 switches our merge pattern from 5.12->5.13->dev >>> to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13. >>> Again, we could of course change that. >> >> >> Yes, but I was attempting to describe the current approach and messed it >> up. > >> -- >> Kari > > > Well, you are still right about the fact that 5.x.z is not in cherry-pick mode > always. How it can happen that people involved in the process aren't always > correct about branching model. That is simply too complex to follow. Yeah, being hard to understand is a disadvantage of the current model. Part of the difficulty is also just the need to be aware of the current status of the branches with respect to release status. Your cherry-pick proposal dodges that with the keywords used in Applies-to field. It requires the bot to understand that. If you take that away, I would guess that contributors would not find it easier to pick all the correct branches to cherry-pick to compared to picking the right branch to submit to. I could imagine a similar approach used for current model to help in choosing the right branch to submit. So picking from dev, stable, LTS and LTS-strict would tell you the correct branch to submit to. Also about the releases waiting for merges. Even if we have two stable branches active and we would then have a blocker relevant for both 5.13.0 and 5.12.2, there is no need to wait for merges. If those release branches already exist, then they won't be merged into. So waiting for the fix to be merged into 5.13 won't change the cherry-pick operation; the two heads and the common ancestor stay the same. Thus once the fix lands in 5.12.2, it can then be directly cherry-picked to 5.13.0. It would have to be cherry-picked anyway. > Btw. it also may add one merge to all merges count I mentioned befor True. -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 it doesn’t help in this setup I think. > > Completely seriously, without any preference to either branching > approach: aren't we going to be in some sort of trouble > with the qt6 branch anyway, no matter what we do? I agree. There is also feature based approach, which would make code uglier... All in all we will pay some price for keeping Qt6 and Qt5 in parallel. > But I don't see how going from merge-forward (except also > merge-backward sometimes) to cherry-pick-backward > (except also cherry-pick forward, or kinda sideways to qt6, and maybe > sometimes merge in some direction) is going > to help us with qt6. These matters seem orthogonal. > > Qt6 and dev are going to diverge. Drastically, eventually. I don't > know how to solve that. A new branching policy > is not going to help with that. It will simplify Qt6 mainly by : - distribution of conflict resolution - Qt6 development will not be delayed by waiting for merges to happen, because some refactoring needs to be done in more stable branches (for example tests) I agree, the branching model is not a silver bullet, it will be ugly anyway, let's not make it very slow in the same time :-) Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 productivity: > > If all it would take to get changes distributed is a cherry-pick, then I can > totally see how this can fly. However with a blocking CI and the rate of > flakyness we are experiencing at least in qtbase, I think this carries a > high risk of slowing down development. Bigger then the current merging strategy? > (...) > It would seem that quite a bit of > tooling needs to be developed first anyway? Nah the cherry-picking bot would be reasonably easy. Sanity bot has the option to warn already built-in, although I haven't looked how to enable it for all non dev branches. Migration itself requires some one time scripting and backups, I guess it would be rather about logistics and synchronization, then technical challenges. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Archiving is working
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: Re: [Development] Archiving is working >>> >>> 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 messages, on the bugtracker, and so on. >>> Breaking them is a big no-no-no. >> >> Another +1. I don't want my commit messages to become useless because of >> broken mailing list archive links. I'm pretty sure I also linked to a >> mailing list thread when I did a bulk Qt 4 jira task cleanup, so if that >> link is now broken it's broken in hundreds of comments. > > +1 from me too > > If the archive can’t be regenerated with the same numbers, aren’t there > backups somewhere that can be restored? > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > Another +1. Not being able to handle this properly reflects poorly on the Qt project, imho. There is (nor was) no need to regenerate the archive, that shouldn't have happened. As it stands, restoring a backup to a new VM and populating that with the entries since the situation arose (ca mid-November, if my memory serves me right) appears as a solution that will keep the integrity of our archives until that date, at the cost of possibly upsetting the integrity of the entries since (could probably also be avoidable but requires more effort). In other words, the longer we're in the current state, the worse the problem becomes. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 should be the first >> branch. >It (mostly) suits *our* needs best for everything to land in dev; but >not all potential contributors have the same priorities as us. Past experience has shown that Eddy is very much correct here. Customers fix in their branch. If you have little knowledge of Qt's internals and you ask this person to fix it in a branch that is not even the one they use puts up an extremely high threshold for contributions. In fact I can recount multiple times when a fix was not suitable for LTS and I requested a patch move to dev and the response was, no time to test that outside my own use case. . Later asking them to also make cherry-picks backwards (in case of conflict), just worsens the situation. We want more contributions from people who have little time for their own project. This suggestion makes is completely counter productive to people not working full time outside of Qt. >> 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 different cases that are not covered by CI - isn’t that >> valuable? >Yes, that is valuable; so is the stability of stable branches. >Users surely have stronger expectations of stability for stable branches than >for cutting-edge first releases of a later minor version. So breakage >in dev (caused by things merged up to it) is less harmful than breakage >in stable (caused by things cherry-picked down to it). >Which of these valuable things do we prize more highly ? I value the customer contribution more than a merge effort on my behalf to keep the repo going. As I said earlier, Liang's merge effort can be distributed and I am happy to to do that for the repo's I maintain. That's how valuable the patch from a random contributor in his context is for me. Mind you the scrutinization in dev needs to be proven first. I don't buy it when we cannot even mange to find enough reviewers for patches. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 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 script we used to have when we were using Perforce. Imagine that > >>with more automation. > > Lars Knoll (25 January 2019 11:08) > > > The risk with this is that we might end up having fixes in a stable > > branch that don’t make it do dev for various reasons, so it’ll regress > > in the next minor release. > > It should be fairly trivial to ensure we tag the cherry-picks in such a > way that some routine script can alert relevant folk to ones that > haven't been sorted out within a month, or before the next release on > the branch they targeted. I think this is less of a reason to worry > than you suppose. > Actually, I share the concern about regressions, if we turn the cherry-pick direction. Yes, we can detect such situations, but it is not given that anyone would act on it. What if an author is not responding or not doing anything about the dev cherry-pick? Who will volunteer to fix the situation? What if, it is actually hard task and it can not be done during a release time window? I really prefer a system that automatically tries to not regress. I believe in transparency; maintenance of stable branch is a cost and cherry-pick from dev to stable shows the cost. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 bug, isn’t it? Why would you spend time on fixing > >>> something in 5.12 without checking whether the issue is still present > >>> in > >>> the latest codebase? Perhaps the issue has been fixed already, just > >>> without the author considering it relevant for 5.12 (perhaps for good > >>> reasons). > >> > >> Why would somebody who maintains a project on Qt5 but made the decision > >> to not migrate it to Qt6 care about fixing the latter? > >> > >> > >> > >> Cheers, > >> Robert > > > > > > Project that is not being updated is not maintained. Not maintained > > projects should not take part of the mainstream. > > > > Cheers, > > > >Jędrek > > > > > > > > > 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 5. They even provide > this fix, but why would they care about making it work in Qt 6? > > Cheers, > Robert 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 change. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 5. They even provide >> this fix, but why would they care about making it work in Qt 6? >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 change. The problem is significantly lower because the amount of patches is smaller. The 5.9 series accepts less patches due to stricter commit policy, but yes we all test such cherry-picks in 5.9, right? -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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: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 bug, isn’t it? Why would you spend > > >>> time on fixing something in 5.12 without checking whether the > > >>> issue is still present in the latest codebase? Perhaps the issue > > >>> has been fixed already, just without the author considering it > > >>> relevant for 5.12 (perhaps for good reasons). > > >> > > >> Why would somebody who maintains a project on Qt5 but made the > > >> decision to not migrate it to Qt6 care about fixing the latter? > > >> > > >> > > >> > > >> Cheers, > > >> Robert > > > > > > > > > Project that is not being updated is not maintained. Not maintained > > > projects > should not take part of the mainstream. > > > > > > Cheers, > > > > > >Jędrek > > > > > > > > > > > > > > > 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 5. They even > > provide this fix, but why would they care about making it work in Qt 6? > > > > Cheers, > > Robert > > 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 change. Don't changes have to go to 5.12 first and then be backported to 5.9 with the current model? > Cheers, > Jędrek > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] HEADS-UP: Branching '5.13' from 'dev' started
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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 change. Mitch Curtis (28 January 2019 16:40) > Don't changes have to go to 5.12 first and then be backported to 5.9 > with the current model? Not strictly, as I understand it. Change needs to land in *some* live branch, but that could be dev - although it'll usually be stable, since it makes little sense to cherry-pick back to LTS a change not also worth making in stable. Once it's landed, it can be cherry-picked back to any LTS. When it is, though, it can be cherry-picked back to several LTS branches at the same time (just as, in Jedrzej's model, we would do to all branches other than dev). Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 be cherrypicked into an LTS version. > > > > martin > > > 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 should be the first > branch. > > 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 different cases that are not covered by CI - isn’t that > valuable? I would think so. Also, in the not-so-uncommon case where there is no really obvious target branch (e.g. because reviewers disagree on whether it's LTS material), people who really want to have that change in another branch for which there was no consensus in the initial review are free to attempt porting the change to that branch, using mainly their own resources, which looks like a fair deal to me under these circumstances. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 > different cases that are not covered by CI - isn’t that valuable? Valuable, but how is that different from today? All it takes is that people run the stable branch, which they should, so as to give more eyes to the thing that needs stability the soonest. I've been doing that for 7 years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
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 well? why don't you do merges instead and leave alone? >> [true story :-)] >> - change can pass the CI and found to be problematic later on >> -- oh, I need to fix my change in 5 branches now? [Gerrit 2.14 has a >> cherry-pick button in the UI now, so this is not a problem with that >> version] >> - automated cherry-pick process/bot/script has to be maintained >> -- one change not merged might lead to lots of changes to fail with >> merge conflicts, staying open in gerrit forever >> -- hey, can you add intelligence to the bot so it know how to merge the >> open changes once the dependency is merged? >> -- hey, can you add intelligence to the bot so it can cherry-pick them >> in the right order?) >> - yes, git-cherry-pick does weird things. I have seen it cherry-picking >> the same change twice without problems (same line twice in the file, I >> think I was an include guard that compiled but behaved weirdly, or similar) >> >> my 2€ > > Thank you for the story, do I get it correctly that the most of problems are > social and global flakiness of the system? > > Cheers, > Jędrek Yes, the system works pretty nice as long as all changes are being merged .. as soon as one change does not get merged (and it is a dependency for other changes) then they start to pile up and somebody has to manually work on them anyways .. usually the Release Manager .. but as said, it works around 80% of the time without issues (other than people with different opinions on how it 'would work better for my particular workflow' and writing customized scripts to keep 'staging' the change without looking at the failures ...) -- Sergio Ahumada sahum...@texla.cl pEpkey.asc Description: application/pgp-keys ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Good idea to update Windows 10 to 1809 - Redstone 5?
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 - Redstone > > 5? > > > > Hi > > > > We have this thing that we like to try to update things to the latest. But > > regarding Windows 10 I was told we shouldn't perhaps do that, because Qt's > > code will select and different path depending on the API levels available > > from Windows. > > Qt WebEngine in Qt 5.13 will require a newer version of Windows 10, so it's > high time to update Windows 10 in our CI. > No, the version of Windows doesn't matter. It is only the version of the Visual Studio 2017 that needs updating. Though they could update both at once. But Qt WebEngine will be fine with just the newest patch release of the compiler :) 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Maintenance break this morning
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 back online. Br Heikki ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
