Re: [Development] Qt modules, API changes and Qt 6
On Thu, Jan 28, 2021 at 04:48:31PM +, Volker Hilsheimer wrote: On 22 Jan 2021, at 12:39, Oswald Buddenhagen wrote: remember that this is only for the commits that explicitly ask for a dep update, and they currently do that by modifying the yaml file. So things either work, or they need some coordination of the change [t]hat fixes, and the change that bumps the dependencies. correct. Maybe we can simplify that whole thing: * by default, there is no sha1 in the dependencies.yaml files If there is none, assume HEAD of the corresponding branch. that makes things confusing and inconsistent. With the big breakages for Qt 6 done, this should work for many modules, most of the time. Many of us are already building a large subset of Qt modules daily from HEAD of all of those modules. the system should be "qt7-safe", though. * only pin the version if the latest HEAD doesn’t work I.e. if current HEAD of qtdeclarative doesn’t pass against new HEAD of qtbase (during the dependency updating round), pin the last-working qtbase revision in qtdeclarative’s dependency.yaml file. I assume we can keep that history of “last sha1 of module that worked” in the CI system rather than in git; if nothing else, we can fall back to whatever is in qt5.git's .gitmodules Once someone has followed up with a patch in qtdeclarative (or qtbase), remove that version pinning again. that's still a second commit in that repo just to remove the pinning. it's maybe not that much noise, but it's ... weird. Eventually, things will be consistent, and .gitmodules gets updated. We won’t have a complete record of all the different qtbase revision against which each qtdeclarative revision tested successfully in the past, but we don't have that that in Qt 5 anyway, and .gitmodules will have equivalent information, at larger intervals. there is no need to resign from a potentially useful feature, though. if checking out a patchset of a qt5 change can give us that state without trading off something significant for it, then that's a good thing. but it might be possible for Coin to try to move things forward automatically, just as we do now with the dependency update bot. yes, of course. the mechanism would stay almost identical, only the state would be keept in a different (more appropriate) place. Storing the state outside of the relevant repository means that we have to stage changes in two repos for things to work again. That makes for a messy orchestration (still less messy than having to get the “proper” .gitmodules updated to a consistent set). huh? the process doesn't have more stages than the current one, only that you'd put the info into the commit message of the affected commit instead of modifying dependencies.yaml in that commit. On Thu, Jan 21, 2021 at 04:20:50PM +, Tor Arne Vestbø wrote: This information does not belong in the commit message. It belongs in dependencies.yaml, that's just something you're postulating, completely ignoring the points made against the very existence of that file. I think it makes sense to recognize that it has become a common practice to document the dependencies of a project in some sort of data file within that project. Wether requirements.txt, package.json, dependencies.yaml, or a “requires” in a conanfile.py. that hasn't "become" common practice - _external_ dependencies were always versioned by the build system (and not some weird parallel specification ...); that's simply part of configuration management. .gitmodules might work for the Qt libraries that are directly under the Qt Project governance, yes: On Thu, Jan 14, 2021 at 11:23:32PM +0100, Oswald Buddenhagen wrote: On Thu, Jan 14, 2021 at 02:08:43PM +, Volker Hilsheimer wrote: Nevertheless, federating the declaration of the dependencies across modules out to each module is the right idea, I think. no, it's not. for tightly bound co-evolving packages, the vcs should provide as much atomicity as reasonably possible. but it won’t help 3rd party libraries. correct. Perhaps there is value in having a more standardised process? the only "standard" you have is your build system, and whatever meta layer you build on top of it in the CI system. i did a lot of related specification work for the latter before i left tqtc, but as soon as i was gone, the concept was dropped - presumably it was "too hard". ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
> On 22 Jan 2021, at 12:39, Oswald Buddenhagen > wrote: > > On Thu, Jan 21, 2021 at 04:06:03PM +, Volker Hilsheimer wrote: Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen: > for example, the information that a build with updated dependencies is > required can be stored as an annotation in the commit message (that's > exactly what zuul does, afaik), and the incremental propagation of the > dependencies can be done in a "shadow" branch of the qt5 repository > (technically, that could be a single gerrit change that gets > progressively updated). > [...] >> >> Do I understand your proposals correctly: >> >> Let’s say I make a change in qtdeclarative that depends on a merged change >> ‘shaA' in qtbase and on ’shaB’ in qtsvg, then I add something like >> >> dependencies: qtbase:shaA qtsvg:shaB >> >> (or whatever syntax we want) to my qtdeclarative commit message? >> > yes. > >> As for the shadow branch(es) in qt5.git or progressively moving gerrit >> change(es): >> >> * change shaX in qtbase merges, breaks qtdeclarative >> * bot updates shadow-branch's .gitmodules to point at qtbase:shaX; it’s now >> inconsistent (qtdeclarative doesn’t build or pass tests) >> * coin keeps testing qtdeclarative changes against qtbase:shaX~1 (as per >> upstream .gitmodules), changes that don’t depend on shaX merge >> * follow-up change shaY in qtdeclarative is staged, with above annotation >> asking for qtbase:shaX >> * coin tests qtdeclarative with shaY against qtbase:shaX, as per the shadow >> branch’s .gitmodules. Tests pass, shaY merges, .gitmodules in shadow branch >> is updated to point at qtdeclarative:shaY >> >> Once the round is complete for all sub modules, the existing git submodule >> update process updates .gitmodules in the proper branch, and reset the >> shadow-branch (I suppose). >> >> Was that the idea, Ossi? >> > i think so. ^^ > >> It puts some extra burden on contributors and reviewers (add commit footer >> with correct sha1, >> > remember that this is only for the commits that explicitly ask for a dep > update, and they currently do that by modifying the yaml file. So things either work, or they need some coordination of the change hat fixes, and the change that bumps the dependencies. Maybe we can simplify that whole thing: * by default, there is no sha1 in the dependencies.yaml files If there is none, assume HEAD of the corresponding branch. With the big breakages for Qt 6 done, this should work for many modules, most of the time. Many of us are already building a large subset of Qt modules daily from HEAD of all of those modules. * only pin the version if the latest HEAD doesn’t work I.e. if current HEAD of qtdeclarative doesn’t pass against new HEAD of qtbase (during the dependency updating round), pin the last-working qtbase revision in qtdeclarative’s dependency.yaml file. I assume we can keep that history of “last sha1 of module that worked” in the CI system rather than in git; if nothing else, we can fall back to whatever is in qt5.git's .gitmodules Once someone has followed up with a patch in qtdeclarative (or qtbase), remove that version pinning again. Eventually, things will be consistent, and .gitmodules gets updated. We won’t have a complete record of all the different qtbase revision against which each qtdeclarative revision tested successfully in the past, but we don't have that that in Qt 5 anyway, and .gitmodules will have equivalent information, at larger intervals. That should reduce the amount of git history noise substantially. >> but it might be possible for Coin to try to move things forward >> automatically, just as we do now with the dependency update bot. >> > yes, of course. the mechanism would stay almost identical, only the state > would be keept in a different (more appropriate) place. Storing the state outside of the relevant repository means that we have to stage changes in two repos for things to work again. That makes for a messy orchestration (still less messy than having to get the “proper” .gitmodules updated to a consistent set). > On Thu, Jan 21, 2021 at 04:20:50PM +, Tor Arne Vestbø wrote: >> This information does not belong in the commit message. >> >> It belongs in dependencies.yaml, >> > that's just something you're postulating, completely ignoring the points made > against the very existence of that file. I think it makes sense to recognize that it has become a common practice to document the dependencies of a project in some sort of data file within that project. Wether requirements.txt, package.json, dependencies.yaml, or a “requires” in a conanfile.py. .gitmodules might work for the Qt libraries that are directly under the Qt Project governance, but it won’t help 3rd party libraries. Perhaps there is value in having a more standardised process? Cheers, Volker ___ Development mailing list
Re: [Development] Qt modules, API changes and Qt 6
On Thu, Jan 21, 2021 at 04:06:03PM +, Volker Hilsheimer wrote: Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen: for example, the information that a build with updated dependencies is required can be stored as an annotation in the commit message (that's exactly what zuul does, afaik), and the incremental propagation of the dependencies can be done in a "shadow" branch of the qt5 repository (technically, that could be a single gerrit change that gets progressively updated). [...] Do I understand your proposals correctly: Let’s say I make a change in qtdeclarative that depends on a merged change ‘shaA' in qtbase and on ’shaB’ in qtsvg, then I add something like dependencies: qtbase:shaA qtsvg:shaB (or whatever syntax we want) to my qtdeclarative commit message? yes. As for the shadow branch(es) in qt5.git or progressively moving gerrit change(es): * change shaX in qtbase merges, breaks qtdeclarative * bot updates shadow-branch's .gitmodules to point at qtbase:shaX; it’s now inconsistent (qtdeclarative doesn’t build or pass tests) * coin keeps testing qtdeclarative changes against qtbase:shaX~1 (as per upstream .gitmodules), changes that don’t depend on shaX merge * follow-up change shaY in qtdeclarative is staged, with above annotation asking for qtbase:shaX * coin tests qtdeclarative with shaY against qtbase:shaX, as per the shadow branch’s .gitmodules. Tests pass, shaY merges, .gitmodules in shadow branch is updated to point at qtdeclarative:shaY Once the round is complete for all sub modules, the existing git submodule update process updates .gitmodules in the proper branch, and reset the shadow-branch (I suppose). Was that the idea, Ossi? i think so. ^^ It puts some extra burden on contributors and reviewers (add commit footer with correct sha1, remember that this is only for the commits that explicitly ask for a dep update, and they currently do that by modifying the yaml file. which will need some extra care when cherry-picking), it would be rather exceptional if such a commit was ever backported, so no problem with that, either. but it might be possible for Coin to try to move things forward automatically, just as we do now with the dependency update bot. yes, of course. the mechanism would stay almost identical, only the state would be keept in a different (more appropriate) place. On Thu, Jan 21, 2021 at 04:20:50PM +, Tor Arne Vestbø wrote: This information does not belong in the commit message. It belongs in dependencies.yaml, that's just something you're postulating, completely ignoring the points made against the very existence of that file. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote: Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen: for example, the information that a build with updated dependencies is required can be stored as an annotation in the commit message (that's exactly what zuul does, afaik), and the incremental propagation of the dependencies can be done in a "shadow" branch of the qt5 repository (technically, that could be a single gerrit change that gets progressively updated). Yeah, I was also thinking of using git notes perhaps for storing the information separately. (Doesn't seem to be enabled in our Gerrit? Hopefully I'm wrong :). i don't think using git notes is particularly useful here. the number of affected commits would be rather low, so having an additional commit message footer would not hurt. extracting that information would also be rather easy (git log from the last reference point). Do I understand your proposals correctly: Let’s say I make a change in qtdeclarative that depends on a merged change ‘shaA' in qtbase and on ’shaB’ in qtsvg, then I add something like dependencies: qtbase:shaA qtsvg:shaB (or whatever syntax we want) to my qtdeclarative commit message? This information does not belong in the commit message. It belongs in dependencies.yaml, and a git-merge-driver for dependencies.yaml should be able to resolve those to a compatible set for each integration, or report back if the dependencies can not be satisfied. This would also avoid the dance we have have (had) where a submodule update needs to be carefully staged with other changes that depend on it or fix something as a result of the update. Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
Reviving this thread as a follow up to the discussion in the “Qt6 repo” thread at https://lists.qt-project.org/pipermail/development/2021-January/040902.html > On 17 Sep 2019, at 14:51, Oswald Buddenhagen > wrote: > > On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote: >> Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen: >>> for example, the information that a build with updated dependencies is >>> required can be stored as an annotation in the commit message (that's >>> exactly what zuul does, afaik), and the incremental propagation of the >>> dependencies can be done in a "shadow" branch of the qt5 repository >>> (technically, that could be a single gerrit change that gets progressively >>> updated). >>> >> Yeah, I was also thinking of using git notes perhaps for storing the >> information separately. (Doesn't seem to be enabled in our Gerrit? Hopefully >> I'm wrong :). >> > i don't think using git notes is particularly useful here. the number of > affected commits would be rather low, so having an additional commit message > footer would not hurt. extracting that information would also be rather easy > (git log from the last reference point). Do I understand your proposals correctly: Let’s say I make a change in qtdeclarative that depends on a merged change ‘shaA' in qtbase and on ’shaB’ in qtsvg, then I add something like dependencies: qtbase:shaA qtsvg:shaB (or whatever syntax we want) to my qtdeclarative commit message? As for the shadow branch(es) in qt5.git or progressively moving gerrit change(es): * change shaX in qtbase merges, breaks qtdeclarative * bot updates shadow-branch's .gitmodules to point at qtbase:shaX; it’s now inconsistent (qtdeclarative doesn’t build or pass tests) * coin keeps testing qtdeclarative changes against qtbase:shaX~1 (as per upstream .gitmodules), changes that don’t depend on shaX merge * follow-up change shaY in qtdeclarative is staged, with above annotation asking for qtbase:shaX * coin tests qtdeclarative with shaY against qtbase:shaX, as per the shadow branch’s .gitmodules. Tests pass, shaY merges, .gitmodules in shadow branch is updated to point at qtdeclarative:shaY Once the round is complete for all sub modules, the existing git submodule update process updates .gitmodules in the proper branch, and reset the shadow-branch (I suppose). Was that the idea, Ossi? It puts some extra burden on contributors and reviewers (add commit footer with correct sha1, which will need some extra care when cherry-picking), but it might be possible for Coin to try to move things forward automatically, just as we do now with the dependency update bot. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Tue, Sep 17, 2019 at 12:39:01PM +, Simon Hausmann wrote: Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen: for example, the information that a build with updated dependencies is required can be stored as an annotation in the commit message (that's exactly what zuul does, afaik), and the incremental propagation of the dependencies can be done in a "shadow" branch of the qt5 repository (technically, that could be a single gerrit change that gets progressively updated). Yeah, I was also thinking of using git notes perhaps for storing the information separately. (Doesn't seem to be enabled in our Gerrit? Hopefully I'm wrong :). i don't think using git notes is particularly useful here. the number of affected commits would be rather low, so having an additional commit message footer would not hurt. extracting that information would also be rather easy (git log from the last reference point). After about 7 months elapsed without anybody picking up a smarter solution, Lars and I sat down and implemented the "dumb" one -- we really want to get going with Qt 6. that seems like rather fallacious thinking. the solution i propose certainly doesn't seem significantly harder than what you did; the main issue is as usual getting past the inertia of the whole system, and you have that anyway. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen: > On Tue, Sep 17, 2019 at 06:56:39AM +, Simon Hausmann wrote: >> When the todo list is empty and there are no more pending updates, >> the batch update is complete. If during that update there were no >> failures, the Qt Module Updater will also push a change to qt5.git >> with an update to all submodule sha1s of the new consistent set of >> modules. >> > an approach that doesn't put redundant dependency information inside > the modules and doesn't spam them with updates to that info would have > been preferable. > > for example, the information that a build with updated dependencies is > required can be stored as an annotation in the commit message (that's > exactly what zuul does, afaik), and the incremental propagation of the > dependencies can be done in a "shadow" branch of the qt5 repository > (technically, that could be a single gerrit change that gets > progressively updated). > Yeah, I was also thinking of using git notes perhaps for storing the information separately. (Doesn't seem to be enabled in our Gerrit? Hopefully I'm wrong :). After about 7 months elapsed without anybody picking up a smarter solution, Lars and I sat down and implemented the "dumb" one -- we really want to get going with Qt 6. I think a transition to a pinning that doesn't "clutter" the history would be preferable / nice to have. Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Tue, Sep 17, 2019 at 06:56:39AM +, Simon Hausmann wrote: When the todo list is empty and there are no more pending updates, the batch update is complete. If during that update there were no failures, the Qt Module Updater will also push a change to qt5.git with an update to all submodule sha1s of the new consistent set of modules. an approach that doesn't put redundant dependency information inside the modules and doesn't spam them with updates to that info would have been preferable. for example, the information that a build with updated dependencies is required can be stored as an annotation in the commit message (that's exactly what zuul does, afaik), and the incremental propagation of the dependencies can be done in a "shadow" branch of the qt5 repository (technically, that could be a single gerrit change that gets progressively updated). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
Hi, I would like to provide an update to this (old) thread based on the development in the past months and weeks. Am 15.02.19 um 10:30 schrieb Frederik Gladhorn: > Hi, > > On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote: >> Summing up the discussion here. It looks like people overall agree that the >> pinned dependency approach (option 3) sounds better than what we currently >> have. The main concern was CI capacity, but Frederik believes that with >> enough storage capacity for build artefacts this will not be worse than >> what we have today with all the failed qt5.git integrations. > >> The only other option that was seriously considered was a more monolithic >> repo (option 4). Disadvantages here are that it would require more work on >> the CI front to make testing times bearable, and it doesn’t give us a very >> flexible approach with regards to adding/removing modules. This is >> something that option 3 will nicely give us, as it treats all repositories >> the same way. Option 3 does btw not exclude that we later on merge some >> repositories if we feel that makes sense. > >> So let’s go with option 3. Frederik will be leading the work to get this >> implemented. > >> As far as I can see, it requires some changes to CI so that we have the >> dependencies encoded in each repository, a bot to automatically push sha1’s >> of dependencies forward and some monitoring to alert us if modules get left >> behind. > > I have indeed been playing with this, and I think I have an implementation > that works when it comes to resolving dependencies based on the idea. > > After some pondering and starting with ini files, I settled on yaml, since we > probably want to extend the data later on and I would like this to be easily > human and machine read- and writable. > > My current files look like this: > dependencies: > qt/qtbase: > ref: 698078680fc5a6870177af285fa50c0d8a7c0bc3 > url: code.qt.io > qt/qtsvg: > ref: 2ae3c52fc061f574c9582bf58963fb3996724fbf > url: code.qt.io > > > This is for qt/qtdeclarative, sha1's taken from qt5.git at some point. > Then there is the question of what the file name should be. Should it be at > the top-level or in a coin subdirectory? dependencies.yaml? > > > I have not yet worked on the bot doing the module updates (which may turn out > to be the harder part). > I don't think this can go live before we have that written as well. Thanks to Frederik and Aapo, Coin has learned to read and utilize the dependencies.yaml files in repositories when present. This permits pinning dependencies to specific sha1s. The second part was a tool to maintain these permanent pinnings, by posting updates to Gerrit through the graph of dependencies. This tool is now ready for use and is based on a fairly simple algorithm. I'd like to put this tool into Gerrit in the near future. Meanwhile, here's a description of how it works from the README: ## Algorithm The process of updating dependencies starts by collecting a list of all repositories and determining the root of the graph. That's typically qtbase. From there one, updates to all repositories are posted that only depend on the root. All other repositories remain in a "todo" list. The root is remembered in a "done" list and all repositories that we are currently trying to bring up-to-date are in a "pending" list. Once this process is started, the program saves its state in a ```.json``` file and terminates. The next time the Qt Module Updater is started, it resumes the state and begins checking the state of all pending updates. If an update succeeded, then the corresponding repository is added to the "done" list and we can prepare updates for repositories that have now their dependencies satisfied by picking them from the "todo" list. If the update failed, the repository is dropped from the batch of updates and all other repositories that directly or indirectly depend on the failed one are also removed. After every such iteration of processing pending updates and pushing new ones to Gerrit, the process terminates and saves its state. When the todo list is empty and there are no more pending updates, the batch update is complete. If during that update there were no failures, the Qt Module Updater will also push a change to qt5.git with an update to all submodule sha1s of the new consistent set of modules. Since this is needed to facilitate private API changes in Qt 6, the objective is to take this into production in either the wip/qt6 branch or dev in the coming days. If you see these files appearing, then you know why :-) There is no immediate plan to take this into use for Qt 5 development. That's not a "never ever!" statement though, more an expression of "let's try this in Qt 6 first". Simon ___ Development mailing list Development@qt-project.org
Re: [Development] Qt modules, API changes and Qt 6
Hi, On fredag 15. februar 2019 07:31:33 CET Lars Knoll wrote: > Summing up the discussion here. It looks like people overall agree that the > pinned dependency approach (option 3) sounds better than what we currently > have. The main concern was CI capacity, but Frederik believes that with > enough storage capacity for build artefacts this will not be worse than > what we have today with all the failed qt5.git integrations. > The only other option that was seriously considered was a more monolithic > repo (option 4). Disadvantages here are that it would require more work on > the CI front to make testing times bearable, and it doesn’t give us a very > flexible approach with regards to adding/removing modules. This is > something that option 3 will nicely give us, as it treats all repositories > the same way. Option 3 does btw not exclude that we later on merge some > repositories if we feel that makes sense. > So let’s go with option 3. Frederik will be leading the work to get this > implemented. > As far as I can see, it requires some changes to CI so that we have the > dependencies encoded in each repository, a bot to automatically push sha1’s > of dependencies forward and some monitoring to alert us if modules get left > behind. I have indeed been playing with this, and I think I have an implementation that works when it comes to resolving dependencies based on the idea. After some pondering and starting with ini files, I settled on yaml, since we probably want to extend the data later on and I would like this to be easily human and machine read- and writable. My current files look like this: dependencies: qt/qtbase: ref: 698078680fc5a6870177af285fa50c0d8a7c0bc3 url: code.qt.io qt/qtsvg: ref: 2ae3c52fc061f574c9582bf58963fb3996724fbf url: code.qt.io This is for qt/qtdeclarative, sha1's taken from qt5.git at some point. Then there is the question of what the file name should be. Should it be at the top-level or in a coin subdirectory? dependencies.yaml? I have not yet worked on the bot doing the module updates (which may turn out to be the harder part). I don't think this can go live before we have that written as well. Cheers, Frederik > Cheers, > Lars > > > > On 30 Jan 2019, at 11:11, Edward Welbourne > > wrote: > > > > Robin Burchell (30 January 2019 10:13) > > > >> I will admit that a monorepo has a _different_ set of problems > >> (including but not limited to: longer build times, longer test times, > >> flaky tests in unrelated areas blocking changes), > > > > > > It also makes it easier to cope with API changes, which is great where > > it's public APIs that haven't yet been shipped, but also makes it easier > > to get away with using private APIs between components that really > > shouldn't do that. One of the classic reasons for modularisation at the > > VC layer is that it makes this sort of thing harder, which means it > > happens less, which is good. > > > > There's also the problem of scope - which things go in the monorepo, > > which should be outside. We have that today, with qt5/, and we should > > probably hoist some of its pieces outside, if only to force ourselves to > > make it easy for a sizeable component to live happily outside; that > > would enable folk in our ecosystem to live happily alongside, rather > > than inside, Qt. If we insist on solving that as part of a switch to a > > monorepo, then we win (even if we could have done it without the > > switch), if only because a major upheaval is an opportunity to make > > other needed changes. But if we move to a monorepo without solving that > > problem, there's a significant risk we'll be making things harder for > > those who work outside but close to Qt. > > > > > >> but those problems are not complex, and can be fixed with some > >> dedicated application of smarter scripting at build/test time > > > > > > I remain to be convinced. > > > > > >> (for instance: if change is doc only, don't run any test that _isn't_ > >> related to documentation, to cover one complaint from earlier in this > >> thread). > > > > > > This sort of thing [*] sounds terribly sensible and feasible, until you > > start running into changes that the submitter and reviewers all *think* > > should only have impact in a bounded area, but that turns out to break > > stuff in surprising places outside those bounds. That's probably rare > > but when it happens it'll gum up the works - in a seemingly not very > > related area that's been caught in the cross-fire. In particular, this > > sort of thing happens more readily when disparate things use each > > others private APIs, as sketched above. > > > > [*] The case of doc fixes is probably relatively safe, of course; but if > > this is applied to other changes, we can't be assured of as much safety. > > One of the scripts involved in my API change review generator knows to > > ignore various changes that "make no
Re: [Development] Qt modules, API changes and Qt 6
Summing up the discussion here. It looks like people overall agree that the pinned dependency approach (option 3) sounds better than what we currently have. The main concern was CI capacity, but Frederik believes that with enough storage capacity for build artefacts this will not be worse than what we have today with all the failed qt5.git integrations. The only other option that was seriously considered was a more monolithic repo (option 4). Disadvantages here are that it would require more work on the CI front to make testing times bearable, and it doesn’t give us a very flexible approach with regards to adding/removing modules. This is something that option 3 will nicely give us, as it treats all repositories the same way. Option 3 does btw not exclude that we later on merge some repositories if we feel that makes sense. So let’s go with option 3. Frederik will be leading the work to get this implemented. As far as I can see, it requires some changes to CI so that we have the dependencies encoded in each repository, a bot to automatically push sha1’s of dependencies forward and some monitoring to alert us if modules get left behind. Cheers, Lars > On 30 Jan 2019, at 11:11, Edward Welbourne wrote: > > Robin Burchell (30 January 2019 10:13) >> I will admit that a monorepo has a _different_ set of problems >> (including but not limited to: longer build times, longer test times, >> flaky tests in unrelated areas blocking changes), > > It also makes it easier to cope with API changes, which is great where > it's public APIs that haven't yet been shipped, but also makes it easier > to get away with using private APIs between components that really > shouldn't do that. One of the classic reasons for modularisation at the > VC layer is that it makes this sort of thing harder, which means it > happens less, which is good. > > There's also the problem of scope - which things go in the monorepo, > which should be outside. We have that today, with qt5/, and we should > probably hoist some of its pieces outside, if only to force ourselves to > make it easy for a sizeable component to live happily outside; that > would enable folk in our ecosystem to live happily alongside, rather > than inside, Qt. If we insist on solving that as part of a switch to a > monorepo, then we win (even if we could have done it without the > switch), if only because a major upheaval is an opportunity to make > other needed changes. But if we move to a monorepo without solving that > problem, there's a significant risk we'll be making things harder for > those who work outside but close to Qt. > >> but those problems are not complex, and can be fixed with some >> dedicated application of smarter scripting at build/test time > > I remain to be convinced. > >> (for instance: if change is doc only, don't run any test that _isn't_ >> related to documentation, to cover one complaint from earlier in this >> thread). > > This sort of thing [*] sounds terribly sensible and feasible, until you > start running into changes that the submitter and reviewers all *think* > should only have impact in a bounded area, but that turns out to break > stuff in surprising places outside those bounds. That's probably rare > but when it happens it'll gum up the works - in a seemingly not very > related area that's been caught in the cross-fire. In particular, this > sort of thing happens more readily when disparate things use each > others private APIs, as sketched above. > > [*] The case of doc fixes is probably relatively safe, of course; but if > this is applied to other changes, we can't be assured of as much safety. > One of the scripts involved in my API change review generator knows to > ignore various changes that "make no difference"; we could apply > something like that to changes to say "needs minimal testing"; but I'd > still worry about the cases where a change makes more difference than > the script maintainer is aware of. Once we get to "this only changes > network code, we don't need to test graphics" (or vice versa) you can > start to expect sporadic surprises. > > Not that the present state of affairs entirely avoids that situation. > In commit qtbase's 641eb4a965 I reverted the introduction of GPU > blacklisting, since it's no longer used; in the process, I renamed > QTestPrivate::checkBlackLists() back to the singular name it'd had > before GPU blcaklists were introduced, confidently expecting that to > have no impact outside QtTestLib. That broke qtdeclarative, because it > actually uses this private API (in implementing the QML test framework), > resulting in a crisis that Liang fixed with qtbase's af6d4d068. That > would have been avoided by a monorepo, but not if we were only building > and testing the parts we believed should be affected. > > So we need to be deliberate about refraining from and objecting to > cross-component use of private parts, all the more so if we're going to > a monorepo. We
Re: [Development] Qt modules, API changes and Qt 6
Robin Burchell (30 January 2019 10:13) > I will admit that a monorepo has a _different_ set of problems > (including but not limited to: longer build times, longer test times, > flaky tests in unrelated areas blocking changes), It also makes it easier to cope with API changes, which is great where it's public APIs that haven't yet been shipped, but also makes it easier to get away with using private APIs between components that really shouldn't do that. One of the classic reasons for modularisation at the VC layer is that it makes this sort of thing harder, which means it happens less, which is good. There's also the problem of scope - which things go in the monorepo, which should be outside. We have that today, with qt5/, and we should probably hoist some of its pieces outside, if only to force ourselves to make it easy for a sizeable component to live happily outside; that would enable folk in our ecosystem to live happily alongside, rather than inside, Qt. If we insist on solving that as part of a switch to a monorepo, then we win (even if we could have done it without the switch), if only because a major upheaval is an opportunity to make other needed changes. But if we move to a monorepo without solving that problem, there's a significant risk we'll be making things harder for those who work outside but close to Qt. > but those problems are not complex, and can be fixed with some > dedicated application of smarter scripting at build/test time I remain to be convinced. > (for instance: if change is doc only, don't run any test that _isn't_ > related to documentation, to cover one complaint from earlier in this > thread). This sort of thing [*] sounds terribly sensible and feasible, until you start running into changes that the submitter and reviewers all *think* should only have impact in a bounded area, but that turns out to break stuff in surprising places outside those bounds. That's probably rare but when it happens it'll gum up the works - in a seemingly not very related area that's been caught in the cross-fire. In particular, this sort of thing happens more readily when disparate things use each others private APIs, as sketched above. [*] The case of doc fixes is probably relatively safe, of course; but if this is applied to other changes, we can't be assured of as much safety. One of the scripts involved in my API change review generator knows to ignore various changes that "make no difference"; we could apply something like that to changes to say "needs minimal testing"; but I'd still worry about the cases where a change makes more difference than the script maintainer is aware of. Once we get to "this only changes network code, we don't need to test graphics" (or vice versa) you can start to expect sporadic surprises. Not that the present state of affairs entirely avoids that situation. In commit qtbase's 641eb4a965 I reverted the introduction of GPU blacklisting, since it's no longer used; in the process, I renamed QTestPrivate::checkBlackLists() back to the singular name it'd had before GPU blcaklists were introduced, confidently expecting that to have no impact outside QtTestLib. That broke qtdeclarative, because it actually uses this private API (in implementing the QML test framework), resulting in a crisis that Liang fixed with qtbase's af6d4d068. That would have been avoided by a monorepo, but not if we were only building and testing the parts we believed should be affected. So we need to be deliberate about refraining from and objecting to cross-component use of private parts, all the more so if we're going to a monorepo. We should also document, alongside each private API, any known violations of its privacy; normally, those are done by friend declarations, but non-class cases (like the QTestPrivate namespace) need comments about such things (and those comments need to be specific enough that someone finding them years later can determine whether they've gone out of date). Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On tirsdag 29. januar 2019 11:07:55 CET Alex Blasche wrote: > >From: Development on behalf of > >Frederik Gladhorn > 2 Heads: use the latest revision of each branch (the system we used to have > in the past) > > >3 Modules containing pinned dependency sha1s > > > >Each module is completely self-contained, that means qt5 is not > > > >required as such (but may still exist as a collection of all modules, for > >convenience and releases). In each module we have a list of dependencies > >and their sha1. > > > >Updates for a release (and also otherwise) must happen regularly > >(e.g. > > > >nightly), moving each module forward towards newer dependencies, this would > >be implemented as bot which updates the above mentioned requirements file. > I like this one. As you mentioned, we kind of had it already with > sync.profiles.And really, if you implement this option you can almost > implicitly run option 2 above too. In fact some modules might even want to > do that if you permit SHA definition based on HEAD of some other > repo/branch. > > There is one big question though. I vaguely recall one of the reasons for > going to today's model was to limit the number of potential builds. This > model could have 10 different modules/repos using different SHA's for all > of its dependencies. Doesn't this increase the amount of different module > builds which you have to store for later CI runs or build e.g. qtbase more > often? Do we have the capacity/storage for it? Yes, this is what we ended up with as well, module pinning seems like the way to go. It seems to solve a bunch of issues and we'd like to try implementing it (a few lines in how the CI resolves dependencies and writing the bot that bumps dependencies forward). The capacity is something to look at, but considering how many failed qt5.git updates we have, I'm actually hoping that we get a better success rate with this model. Other things to figure out are provisioning (how we prepare the VMs on which we build and test) and what the files specifying the dependencies should look like. So option 3 is the favorite, but we need to clarify a few details. Cheers, Frederik > > -- > Alex > ___ > 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] Qt modules, API changes and Qt 6
On onsdag 30. januar 2019 09:17:11 CET Alex Blasche wrote: > >From: Development on behalf of Jedrzej > >Nowacki > > >Personally, I also do like the idea of monolithic repo, while keeping > > > >modularization on the logical / build level. In our current state I see two > >major problems: > >- our build is quite monolithic in practice. For example qtbase always > >needs to be build. CI currently caches builds on repository level (caches > >results of make install) with monolithic repository the optimization would > >need to be reconstructed on the build level. Conceptually it is good, but > >someone would need to do the work. > >- as a consequence of a partial build, the repository may be in a broken > >state, for example not compiling. It can be solved by time based world > >rebuilding and tagging known good revisions, but some policies would need > >to be created. > > I am clearly missing something here. Could you please outline why such a > monolithic repo would be good? As you pointed out yourself, the conceptual > problem that different libraries won't walk in lockstep remains and > segmented builds continue to be desired. Sure, repo checkout is easier but > as long as segmentation exists I fail to see the advantage. A mono repo is good because it allows changing API across modules in on go. There are a bunch of things speaking in favor of this, but the practicalities are quite hard - how would we do CI for this? How would we merge between the mono repo and the existing individual repos? In the end we discarded the idea as impractical for the time being. It would be possible for someone to champion it by showing a lot of git magic and coming up with a good testing strategy where things work together nicely, but I fear that the complexity is quite high. With unlimited resources we could of course test everything in the repo for each change. Other options would be to try to figure out which tests are relevant for which change. Doing that cross- platform in a sensible way seems quite non-trivial as well. Cheers, Frederik > > -- > Alex > ___ > 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] Qt modules, API changes and Qt 6
On Wed, Jan 30, 2019, at 9:17 AM, Alex Blasche wrote: > I am clearly missing something here. Could you please outline why such a > monolithic repo would be good? As you pointed out yourself, the > conceptual problem that different libraries won't walk in lockstep > remains and segmented builds continue to be desired. Sure, repo checkout > is easier but as long as segmentation exists I fail to see the > advantage. Split repositories have a lot of problems, both social, and technical, but I'd say that it all boils down to extra friction. On the technical side, you have the well-known problem of API changes. When you make one, you have to make it in a backwards-compatible way, integrate that into qt5, then change everything, integrate that into qt5, then remove the backwards compatibility. That's a long process, even if everything goes perfectly (reviews are easy, happen quickly, CI isn't flaky, etc, etc). Then you have the social side of it. Basically, I think I can summarize it as being this: a repository boundary generally makes a problem into "someone else's problem" rather than "my problem" or "our problem", because the perception is it's easier that way, even if the cohesive whole ends up suffering as a result. I will admit that a monorepo has a _different_ set of problems (including but not limited to: longer build times, longer test times, flaky tests in unrelated areas blocking changes), but those problems are not complex, and can be fixed with some dedicated application of smarter scripting at build/test time (for instance: if change is doc only, don't run any test that _isn't_ related to documentation, to cover one complaint from earlier in this thread). I don't think that changing the technology behind how we contribute today would necessarily fix any of this split repo stuff either, I think a lot of it is just inherent to how such a system works. For instance, a project I am currently working on uses a completely different toolset, yet suffered from (a version of) exactly the problems outlined here -- and once we realised just how hard that was making life, and merged a bunch of repositories together, suddenly, things became a lot easier. The repository merge, in our case, helped to inspire actually applying work to _fix_ those problems rather than just working around them by splitting things into smaller pieces, too. Another real life anecdote: when I merged together our bunch of repositories, I was annoyed by ~20 minute clean build times of one component in our CI pipeline. I found out that it was due to heavy (ab)use of templates, which I managed to work around in a largely source-compatible way, and dropped the build time of that component down to ~3 minutes, which certainly made the people working on that component happy. I wouldn't have done it without the repository merge, partly because it wasn't "my problem" before, and partly because I just didn't notice, as I didn't work on that component: I still don't, really, but because I live near it, I see the code in grep results. I see the impact it has on build/test times, and so on. Robin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
>From: Development on behalf of Jedrzej >Nowacki >Personally, I also do like the idea of monolithic repo, while keeping >modularization on the logical / build level. In our current state I see two >major problems: >- our build is quite monolithic in practice. For example qtbase always needs >to be build. CI currently caches builds on repository level (caches results of >make install) with monolithic repository the optimization would need to be >reconstructed on the build level. Conceptually it is good, but someone would >need to do the work. >- as a consequence of a partial build, the repository may be in a broken >state, for example not compiling. It can be solved by time based world >rebuilding and tagging known good revisions, but some policies would need to >be created. I am clearly missing something here. Could you please outline why such a monolithic repo would be good? As you pointed out yourself, the conceptual problem that different libraries won't walk in lockstep remains and segmented builds continue to be desired. Sure, repo checkout is easier but as long as segmentation exists I fail to see the advantage. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Sunday, January 27, 2019 11:47:04 AM CET Harri Porten wrote: > On Sat, 26 Jan 2019, Olivier Goffart wrote: > > I think the "monorepo" is clearly a good approach. And git is evolving > > with > > shadow clones and partial checkout. LLVM/Clang recently choose the > > monorepo > > approach as it moves to git. > > > > Of one problem is that this will make CI integration slower because each > > CI > > run now have to test both qtbase and qtdeclarative tests. > > I've started to develop sympathy for "monorepos" during the last years. To > counter often expressed fears like excessive build and test times one has > to point out: > > Bigger (or even single) repositories do NOT mean > >- monolithic builds and test runs >- monolithic packaging > > Developers and packagers are free to model logical segements according to > their needs. > > Harri. Hi, Personally, I also do like the idea of monolithic repo, while keeping modularization on the logical / build level. In our current state I see two major problems: - our build is quite monolithic in practice. For example qtbase always needs to be build. CI currently caches builds on repository level (caches results of make install) with monolithic repository the optimization would need to be reconstructed on the build level. Conceptually it is good, but someone would need to do the work. - as a consequence of a partial build, the repository may be in a broken state, for example not compiling. It can be solved by time based world rebuilding and tagging known good revisions, but some policies would need to be created. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
>From: Development on behalf of Frederik >Gladhorn 2 Heads: use the latest revision of each branch (the system we used to have in the past) >3 Modules containing pinned dependency sha1s >Each module is completely self-contained, that means qt5 is not >required as such (but may still exist as a collection of all modules, for >convenience and releases). In each module we have a list of dependencies and >their sha1. >Updates for a release (and also otherwise) must happen regularly (e.g. >nightly), moving each module forward towards newer dependencies, this would be >implemented as bot which updates the above mentioned requirements file. I like this one. As you mentioned, we kind of had it already with sync.profiles.And really, if you implement this option you can almost implicitly run option 2 above too. In fact some modules might even want to do that if you permit SHA definition based on HEAD of some other repo/branch. There is one big question though. I vaguely recall one of the reasons for going to today's model was to limit the number of potential builds. This model could have 10 different modules/repos using different SHA's for all of its dependencies. Doesn't this increase the amount of different module builds which you have to store for later CI runs or build e.g. qtbase more often? Do we have the capacity/storage for it? -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
Here are the options we discussed internally. I'm happy to elaborate more in case something is unclear. 1 Do nothing / today / qt5.git 2 Heads: use the latest revision of each branch (the system we used to have in the past) 3 Modules containing pinned dependency sha1s Each module is completely self-contained, that means qt5 is not required as such (but may still exist as a collection of all modules, for convenience and releases). In each module we have a list of dependencies and their sha1. Updates for a release (and also otherwise) must happen regularly (e.g. nightly), moving each module forward towards newer dependencies, this would be implemented as bot which updates the above mentioned requirements file. 4 Monolithic repository for essentials Merging at least qtbase and qtdeclarative and probably a whole lot more into one repository. Likely excluding webengine and webkit. 5 A way to stage breaking changes across modules (updating for example qtbase, qtdeclarative and qt5.git at the same time) Presumably do some annotation of the commit message in Gerrit, or figure out how to connect changes in Gerrit in another way. I made a small table on the wiki: https://wiki.qt.io/Qt6_Enabling_API_Changes Some notes: 1: is where we are today and in my opinion our processes get in our ways 2: we used to have this, it has the problem that some modules are always failing tests due to their dependencies changing. That's an unfortunate situation. We want to find out about breakages due to dependencies quickly but don't want to block development. 3: All modules get the same treatment and it makes things more consistent. At the same time we really need a bot then that moves modules forward with respect to their dependencies. We would also want to have a visualization that shows how much a module is behind e.g. qtbase (in days and number of commits). We almost had this before in the form of sync.profile where pinning was an option. This proposal does the pinning always and will result in a lot of commits that simply say: bump dependency versions. 4: Requires finding out how to run the CI on this. It's in many ways attractive, but we would always struggle with defining what's in and what not. I see Qt also as ecosystem where modules join and sometimes get left behind. We want to enable that more, so the mono repo approach seems tricky in that respect. That doesn't prevent deciding on some repos being merged. Merging between Qt 5 and 6 will then be harder though. 5: This is more of a cludge and could allow staging changes in qtbase and qtdeclarative at the same time while also trying to update qt5.git. It's a bit complex and needs people to be very aware of it and will block other changes from being processed at the same time. Cheers, Frederik ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Fri, Jan 25, 2019 at 01:12:11PM +, Frederik Gladhorn wrote: > qt5.git serves several purposes today, for example: > - it contains a few binaries needed for Windows development > that's rather trivial, and the only reason i didn't fix it years ago is that factoring these out to another repo would cause everyone cloning *two* instances of somewhat big-ish stuff they probably don't need. if we accept that accurate historical checkouts of these binaries are irrelevant, it would be possible to permanently excise them via git object replacement nowadays. > - it gives a definition of which modules make up a Qt release > - it collects sets of revisions which work together (because they were tested > with each other) > - it has a bit of build system infrastructure to build all of this > > In my opinion there are a few issues with what we have: > - updating qt5.git (and thus making releases) is cumbersome > - it's unclear for many people what a module is tested against in the CI > (its dependencies are checked out at the revisions specified in qt5.git, > not > the latest revisions of the corresponding branch) > > [and some other spread out mentions of related issues] > https://bugreports.qt.io/browse/QTQAINFRA-868 > - we have more products, such as Qt for Automotive, Automation, Device > Creation, should those have qt5-special-purpose repositories? > no. these somewhat arbitrarily defined products don't need to be reflected in the supermodule itself. > - modules outside of qt5.git get different treatment, making it hard > to include new modules > the solution to that is simple: don't have "proper" qt modules outside qt5. the only reason for the current situation is an irrational fear of the kde free qt foundation, because, gee, referencing a repo from a git supermodule is *just* the same as "marketing it as part of qt". for private modules, a private branch of qt5 can be maintained (in the qt5 shadow repo; it can't be in the main one due to gerrit "limitations"). big "leaf" modules which intend to be separate products with independent release cycles (e.g., qtwebkit and qtwebengine) can/should live outside the super repo, because the advantages of detaching them outweigh the additional bother this causes. > Modules are not self-contained (since the fine-grained dependencies > are specified in qt5.git). We don't know how to cleanly handle > dependencies for modules outside. > the current structure is optimized for init-repository, which vastly simplifies the life of developers and is also taken advantage of by the CI system. if you want to move away from a simple supermodule, you'll need a complex meta structure instead. you'll need to extract the dependencies from the repositories (hey, a sanely machine readable build system would have helped with that - too bad the idea was abandoned) and centralize them in a living document which is fetched by whatever checkout script you come up with. you can get some inspiration from kde. you can expect opposition to _requiring_ additional scripts to just get a workable checkout. and google is moving away from "repo" in favor of git native functionality. note that atomic versioning of the dependencies (which is something you need if you expect bisect to be actually useful) is totally impractical to implement with only in-module dependencies. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Sat, 26 Jan 2019, Olivier Goffart wrote: I think the "monorepo" is clearly a good approach. And git is evolving with shadow clones and partial checkout. LLVM/Clang recently choose the monorepo approach as it moves to git. Of one problem is that this will make CI integration slower because each CI run now have to test both qtbase and qtdeclarative tests. I've started to develop sympathy for "monorepos" during the last years. To counter often expressed fears like excessive build and test times one has to point out: Bigger (or even single) repositories do NOT mean - monolithic builds and test runs - monolithic packaging Developers and packagers are free to model logical segements according to their needs. Harri. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On 25.01.19 14:12, Frederik Gladhorn wrote: Hi all, I'd like to start another discussion around our development workflow. We arrived at our current model of Qt modules (in the git repository sense) and using qt5.git as a container for all of them through a series of steps and changes. Mix in the evolution of the testing environment over time and we have something that has grown in interesting ways. I will try to describe the problem in this mail. I also have discussed with a bunch of people (inside The Qt Company) about potential solutions. After brainstorming and some back and forth, we had five suggestions on a whiteboard and picked our favorite. In a separate mail I'll try to describe these and what we concluded with as our favorite. All of this is up for discussion, so I'm hoping for someone to come up with even better ideas. In my opinion, I think it would be much easier to merge a bunch of repository together. Maybe modularisation went to far. QtQuick is a very important part of Qt, and therefore it would make sense to merge qtdeclarative into qtbase. Also small repository could go back in qtbase. Of course, I wouldn't want to merge big repository such as qtwebengine into qtbase. IMHO there are these factor that should come into play: - How much is that module important for Qt? - How big is that module? - How much of private API is that module using (and is it possible to use less of private API?) - ... I think the "monorepo" is clearly a good approach. And git is evolving with shadow clones and partial checkout. LLVM/Clang recently choose the monorepo approach as it moves to git. Of one problem is that this will make CI integration slower because each CI run now have to test both qtbase and qtdeclarative tests. We have to say how much this is a problem compared the the simplicity of development. I'd claim this in some respect, it is actually an advantage, for changes in qtcore. Maybe CI bot could have a simple list of directory that white, or blacklist tests to run depending on the touched directories. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
25.01.2019, 18:11, "Allan Sandfeld Jensen" : > I think for something like qt6, I would like to suggest I think I have brought > up before in relation to testing qt5.git changes on more platforms or > configuations: A system for non blocking CI failures. > > In WebKit they what they called the CI-waterfall. It was a table with commits > as rows and platforms as columns. https://build.webkit.org/waterfall > Only some platforms were blocking and could > prevent patches from integrating(Apple's own of course), the rest was non > blocking and would just turn red on the waterfall when they broke. There is another set of build bots called EWS, they build each revision of submitted patch, so that both patch authors reviewers can be sure that patch builds on all major platforms when discussing code changes. In Qt it sometimes happens that problems are only discovered after +2, leading to anpother review cycle. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Freitag, 25. Januar 2019 14:12:11 CET Frederik Gladhorn wrote: > Hi all, > > I'd like to start another discussion around our development workflow. > We arrived at our current model of Qt modules (in the git repository sense) > and using qt5.git as a container for all of them through a series of steps > and changes. Mix in the evolution of the testing environment over time and > we have something that has grown in interesting ways. > > I will try to describe the problem in this mail. I also have discussed with > a bunch of people (inside The Qt Company) about potential solutions. After > brainstorming and some back and forth, we had five suggestions on a > whiteboard and picked our favorite. In a separate mail I'll try to describe > these and what we concluded with as our favorite. All of this is up for > discussion, so I'm hoping for someone to come up with even better ideas. > > > The problem: > > qt5.git serves several purposes today, for example: > - it contains a few binaries needed for Windows development > - it gives a definition of which modules make up a Qt release > - it collects sets of revisions which work together (because they were > tested with each other) > - it has a bit of build system infrastructure to build all of this > > In my opinion there are a few issues with what we have: > - updating qt5.git (and thus making releases) is cumbersome > - it's unclear for many people what a module is tested against in the CI > (its dependencies are checked out at the revisions specified in qt5.git, > not the latest revisions of the corresponding branch) > - we have more products, such as Qt for Automotive, Automation, Device > Creation, should those have qt5-special-purpose repositories? > - modules outside of qt5.git get different treatment, making it hard to > include new modules > > In the light of Qt 6, there is also the question of how we can allow making > source incompatible changes in an easy fashion. > Why is it hard to do source incompatible changes? Let's say we want to > rename a function in qtbase. qtdeclarative is the only user of that > function in our code-base. Today we can do that in five easy steps: > > 1) add function with new name in qtbase, do not remove the old one yet > 2) update qt5.git > 3+4) move qtdeclarative to the new function name; remove the old function > from qtbase > 5) after 3 and 4 are in, update qt5.git > > Five commits, two of which are qt5.git updates, is a lot to ask for. And > this is assuming that the contributor knows of this work-flow and does > everything by the unwritten book. In the unhappy case, we do an attempt of > changing qtbase directly, then we notice qt5.git doesn't update and we need > to bring back the old function name first. Another aspect is that even > after 5, if this happened to be a branch other than dev, we might face all > of these problems while doing merges to the next branch again (been there, > done that, and so has Liang). > > This has led to a mess in how we create releases and how we test things. It > creates a very hard and artificial line of what's part of the core product > and what is outside and testing in the CI is also majorly influenced by > this. Modules are not self-contained (since the fine-grained dependencies > are specified in qt5.git). We don't know how to cleanly handle dependencies > for modules outside. We have trouble getting some of the releases out, > since Qt for Device Creation follows slightly different routines than Qt > for Application Development > I think for something like qt6, I would like to suggest I think I have brought up before in relation to testing qt5.git changes on more platforms or configuations: A system for non blocking CI failures. In WebKit they what they called the CI-waterfall. It was a table with commits as rows and platforms as columns. Only some platforms were blocking and could prevent patches from integrating(Apple's own of course), the rest was non blocking and would just turn red on the waterfall when they broke. If we had something like this for qt6, and instead of having a qt6.git to begin with just tested the qt6 head of all modules, a source incompatible change would turn the waterfall red for all the modules that broke, we would know which commit caused it, but could work on making the original change more source compatible in qtbase, or fix the modules depending on it one at a time with too much overhead. Once we had a system like that, we could also use to monitor if changes in modules causes other modules to break before qt5.git (or qt6.git) is updated, and test more platforms and configurations without blocking integration more than we already do. best regards 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
> -Original Message- > From: Development On Behalf Of > Frederik Gladhorn > Sent: Friday, 25 January 2019 2:12 PM > To: development@qt-project.org > Subject: [Development] Qt modules, API changes and Qt 6 > > Hi all, > > I'd like to start another discussion around our development workflow. > We arrived at our current model of Qt modules (in the git repository sense) > and using qt5.git as a container for all of them through a series of steps and > changes. Mix in the evolution of the testing environment over time and we > have something that has grown in interesting ways. > > I will try to describe the problem in this mail. I also have discussed with a > bunch of people (inside The Qt Company) about potential solutions. After > brainstorming and some back and forth, we had five suggestions on a > whiteboard and picked our favorite. In a separate mail I'll try to describe > these and what we concluded with as our favorite. All of this is up for > discussion, so I'm hoping for someone to come up with even better ideas. > > > The problem: > > qt5.git serves several purposes today, for example: > - it contains a few binaries needed for Windows development > - it gives a definition of which modules make up a Qt release > - it collects sets of revisions which work together (because they were tested > with each other) > - it has a bit of build system infrastructure to build all of this > > In my opinion there are a few issues with what we have: > - updating qt5.git (and thus making releases) is cumbersome > - it's unclear for many people what a module is tested against in the CI > (its dependencies are checked out at the revisions specified in qt5.git, not > the latest revisions of the corresponding branch) > - we have more products, such as Qt for Automotive, Automation, Device > Creation, should those have qt5-special-purpose repositories? > - modules outside of qt5.git get different treatment, making it hard to > include new modules > > In the light of Qt 6, there is also the question of how we can allow making > source incompatible changes in an easy fashion. > Why is it hard to do source incompatible changes? Let's say we want to > rename a function in qtbase. qtdeclarative is the only user of that function > in > our code-base. Today we can do that in five easy steps: > > 1) add function with new name in qtbase, do not remove the old one yet > 2) update qt5.git > 3+4) move qtdeclarative to the new function name; remove the old > 3+function from > qtbase > 5) after 3 and 4 are in, update qt5.git > > Five commits, two of which are qt5.git updates, is a lot to ask for. And this > is > assuming that the contributor knows of this work-flow and does everything > by the unwritten book. In the unhappy case, we do an attempt of changing > qtbase directly, then we notice qt5.git doesn't update and we need to bring > back the old function name first. Another aspect is that even after 5, if this > happened to be a branch other than dev, we might face all of these > problems while doing merges to the next branch again (been there, done > that, and so has Liang). > > This has led to a mess in how we create releases and how we test things. It > creates a very hard and artificial line of what's part of the core product and > what is outside and testing in the CI is also majorly influenced by this. > Modules are not self-contained (since the fine-grained dependencies are > specified in qt5.git). We don't know how to cleanly handle dependencies for > modules outside. We have trouble getting some of the releases out, since Qt > for Device Creation follows slightly different routines than Qt for > Application > Development > > On a semi-related note, running git-bisect on anything but qtbase is a > science, hard enough to at least put me off. Indeed. For anyone who might be interested, I've found the best way to bisect leaf modules like qtquickcontrols2 (which relies on qtdeclarative and qtbase) is to use qt5.git submodule updates: 1. Clone qt5.git, init only the modules you're interested in. 2. Look for qt5.git submodule updates (e.g. by searching in Gerrit) that happened before and after the issue started happening. Use these as the good/bad commits for the bisect. 3. Run "git submodule update --init qtbase qtxmlpatterns qtdeclarative" (passing in each module you're interested in) after each bisect round to checkout the relevant submodule commits for that qt5.git commit. 4. Wipe the Qt build, configure and build it, then test. 5. Once you've found the bad qt5.git commit, look through (bisect if possible) the range of commits for that in the relevant submodules. This is super slow, but it's the most reliable way, avoiding compiler errors etc
[Development] Qt modules, API changes and Qt 6
Hi all, I'd like to start another discussion around our development workflow. We arrived at our current model of Qt modules (in the git repository sense) and using qt5.git as a container for all of them through a series of steps and changes. Mix in the evolution of the testing environment over time and we have something that has grown in interesting ways. I will try to describe the problem in this mail. I also have discussed with a bunch of people (inside The Qt Company) about potential solutions. After brainstorming and some back and forth, we had five suggestions on a whiteboard and picked our favorite. In a separate mail I'll try to describe these and what we concluded with as our favorite. All of this is up for discussion, so I'm hoping for someone to come up with even better ideas. The problem: qt5.git serves several purposes today, for example: - it contains a few binaries needed for Windows development - it gives a definition of which modules make up a Qt release - it collects sets of revisions which work together (because they were tested with each other) - it has a bit of build system infrastructure to build all of this In my opinion there are a few issues with what we have: - updating qt5.git (and thus making releases) is cumbersome - it's unclear for many people what a module is tested against in the CI (its dependencies are checked out at the revisions specified in qt5.git, not the latest revisions of the corresponding branch) - we have more products, such as Qt for Automotive, Automation, Device Creation, should those have qt5-special-purpose repositories? - modules outside of qt5.git get different treatment, making it hard to include new modules In the light of Qt 6, there is also the question of how we can allow making source incompatible changes in an easy fashion. Why is it hard to do source incompatible changes? Let's say we want to rename a function in qtbase. qtdeclarative is the only user of that function in our code-base. Today we can do that in five easy steps: 1) add function with new name in qtbase, do not remove the old one yet 2) update qt5.git 3+4) move qtdeclarative to the new function name; remove the old function from qtbase 5) after 3 and 4 are in, update qt5.git Five commits, two of which are qt5.git updates, is a lot to ask for. And this is assuming that the contributor knows of this work-flow and does everything by the unwritten book. In the unhappy case, we do an attempt of changing qtbase directly, then we notice qt5.git doesn't update and we need to bring back the old function name first. Another aspect is that even after 5, if this happened to be a branch other than dev, we might face all of these problems while doing merges to the next branch again (been there, done that, and so has Liang). This has led to a mess in how we create releases and how we test things. It creates a very hard and artificial line of what's part of the core product and what is outside and testing in the CI is also majorly influenced by this. Modules are not self-contained (since the fine-grained dependencies are specified in qt5.git). We don't know how to cleanly handle dependencies for modules outside. We have trouble getting some of the releases out, since Qt for Device Creation follows slightly different routines than Qt for Application Development On a semi-related note, running git-bisect on anything but qtbase is a science, hard enough to at least put me off. Cheers, Frederik ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
