[Development] hey kid stfu
69 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote: > I want to summarize intermediate results of the discussion and return it > back to the track. > > > Subject: using smart pointers in the API. > Good idea. Better to use than not because of automatic lifetime > management, *shrug* You seem to repeat your initial statements. QObject parents _do_ manage lifetime to start with. > Subject: raw pointers for passing mandatory parameters vs. using > references. > Allow both approaches, recommend using references (and/or smart > pointers) when acceptable. > Not too many arguments collected here, just > try to make Qt API more modern. Again only your statement. The issue itself has been discussed over and over again. Allowing _both_ I have not seen actively endorsed by anyone, this only makes a messy incosnsistent API. > There are a few irrelevant discussions. Start a new thread if you want > to continue discussing them, please. > > Irrelevant subject: smart pointers vs. parent-child lifetime management > model. Sure. Because it would void the 'lifetime management' line of reasoning. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Heads up: Merge of qtbase/wip/cmake to qtbase/dev soon
Not in the CI yet. Was polishing things locally. But should add that soon. > On 11. Feb 2020, at 16:56, Kyle Edwards wrote: > > Great news! > > Are you using Ninja Multi-Config yet? :) > > Kyle > > On Tue, Feb 11, 2020 at 10:40 AM Alexandru Croitor > wrote: >> >> I published the Qt 6 CMake Port slides that I presented at Qt Contributor >> Summit in 2019. >> >> https://github.com/alcroito/qt6_cmake_port_slides >> >> It might be a bit outdated compared to today's state, but still has some >> useful info to ease into the whole thing as an alternative to the >> cmake/READMEmd. >> >>> On 11. Feb 2020, at 16:29, Tor Arne Vestbø wrote: >>> >>> Great! Thanks for the heads up! >>> >>> Tor Arne >>> On 11 Feb 2020, at 16:17, Alexandru Croitor wrote: Hi, Short PSA. The merge of wip/cmake to dev is done. I'm enabling enforcing CMake builds in dev branch. CMake build phase will have to pass , tests can still fail and it won't fail integrations. In case some build system .pro change sneaks in between the merge and the enabling of enforcing CMake Coin, all dev integrations will fail for a bit. I'll fix that up. But afterwards, regeneration of the CMake projects will be the responsibility of the person changing the .pro / .pri / .qrc / configure.json file. If you don't know how to do that, you can come to freenode #qt-cmake for help. Just in case: README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide Regards, Alexandru. > On 3. Feb 2020, at 14:52, Alexandru Croitor > wrote: > > Hi, > > The Qt CMake Port team would like to merge the wip/cmake branch of qtbase > to dev, soon™ (this week or next week). > > This is mostly a heads up email, so that it doesn't come as a total > surprise. > > How this affects people: > > 1) The qmake Coin builds are still there and continue to work. > > 2) Soon after the merge, a qt5.git change will land which will add a few > more qtbase Coin configurations which will build qtbase with CMake. > > 3) If these CMake Coin builds fail, developers of the respective changes > will have to adapt their changes to fix the CMake builds. > > 3.1) Most of these fixes can probably be done automatically by running > the magical pro2cmake.py script on the build system parts you changed. > > 4) The CMake port in not yet complete. > > 4.1) Not all tests are passing the test phase yet, that's why Coin > ignores test phase errors and will always say that test phase passed > successfully. The important part is that tests *build* successfully. > > > Preliminary tests showed that nothing breaks in Coin as a result of the > merge. > > > The current merge diff is at: > https://codereview.qt-project.org/c/qt/qtbase/+/282101 > > README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake > Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide > > Regards, > Alexandru. ___ 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 mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Heads up: Merge of qtbase/wip/cmake to qtbase/dev soon
Great news! Are you using Ninja Multi-Config yet? :) Kyle On Tue, Feb 11, 2020 at 10:40 AM Alexandru Croitor wrote: > > I published the Qt 6 CMake Port slides that I presented at Qt Contributor > Summit in 2019. > > https://github.com/alcroito/qt6_cmake_port_slides > > It might be a bit outdated compared to today's state, but still has some > useful info to ease into the whole thing as an alternative to the > cmake/READMEmd. > > > On 11. Feb 2020, at 16:29, Tor Arne Vestbø wrote: > > > > Great! Thanks for the heads up! > > > > Tor Arne > > > >> On 11 Feb 2020, at 16:17, Alexandru Croitor > >> wrote: > >> > >> Hi, > >> > >> Short PSA. > >> > >> The merge of wip/cmake to dev is done. > >> > >> I'm enabling enforcing CMake builds in dev branch. CMake build phase will > >> have to pass , tests can still fail and it won't fail integrations. > >> > >> In case some build system .pro change sneaks in between the merge and the > >> enabling of enforcing CMake Coin, all dev integrations will fail for a > >> bit. I'll fix that up. > >> > >> But afterwards, regeneration of the CMake projects will be the > >> responsibility of the person changing the .pro / .pri / .qrc / > >> configure.json file. > >> If you don't know how to do that, you can come to freenode #qt-cmake for > >> help. > >> > >> > >> Just in case: > >> > >> README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake > >> Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide > >> > >> > >> Regards, > >> > >> Alexandru. > >> > >>> On 3. Feb 2020, at 14:52, Alexandru Croitor > >>> wrote: > >>> > >>> Hi, > >>> > >>> The Qt CMake Port team would like to merge the wip/cmake branch of qtbase > >>> to dev, soon™ (this week or next week). > >>> > >>> This is mostly a heads up email, so that it doesn't come as a total > >>> surprise. > >>> > >>> How this affects people: > >>> > >>> 1) The qmake Coin builds are still there and continue to work. > >>> > >>> 2) Soon after the merge, a qt5.git change will land which will add a few > >>> more qtbase Coin configurations which will build qtbase with CMake. > >>> > >>> 3) If these CMake Coin builds fail, developers of the respective changes > >>> will have to adapt their changes to fix the CMake builds. > >>> > >>> 3.1) Most of these fixes can probably be done automatically by running > >>> the magical pro2cmake.py script on the build system parts you changed. > >>> > >>> 4) The CMake port in not yet complete. > >>> > >>> 4.1) Not all tests are passing the test phase yet, that's why Coin > >>> ignores test phase errors and will always say that test phase passed > >>> successfully. The important part is that tests *build* successfully. > >>> > >>> > >>> Preliminary tests showed that nothing breaks in Coin as a result of the > >>> merge. > >>> > >>> > >>> The current merge diff is at: > >>> https://codereview.qt-project.org/c/qt/qtbase/+/282101 > >>> > >>> README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake > >>> Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide > >>> > >>> Regards, > >>> Alexandru. > >> > >> ___ > >> 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 mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Heads up: Merge of qtbase/wip/cmake to qtbase/dev soon
I published the Qt 6 CMake Port slides that I presented at Qt Contributor Summit in 2019. https://github.com/alcroito/qt6_cmake_port_slides It might be a bit outdated compared to today's state, but still has some useful info to ease into the whole thing as an alternative to the cmake/READMEmd. > On 11. Feb 2020, at 16:29, Tor Arne Vestbø wrote: > > Great! Thanks for the heads up! > > Tor Arne > >> On 11 Feb 2020, at 16:17, Alexandru Croitor wrote: >> >> Hi, >> >> Short PSA. >> >> The merge of wip/cmake to dev is done. >> >> I'm enabling enforcing CMake builds in dev branch. CMake build phase will >> have to pass , tests can still fail and it won't fail integrations. >> >> In case some build system .pro change sneaks in between the merge and the >> enabling of enforcing CMake Coin, all dev integrations will fail for a bit. >> I'll fix that up. >> >> But afterwards, regeneration of the CMake projects will be the >> responsibility of the person changing the .pro / .pri / .qrc / >> configure.json file. >> If you don't know how to do that, you can come to freenode #qt-cmake for >> help. >> >> >> Just in case: >> >> README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake >> Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide >> >> >> Regards, >> >> Alexandru. >> >>> On 3. Feb 2020, at 14:52, Alexandru Croitor wrote: >>> >>> Hi, >>> >>> The Qt CMake Port team would like to merge the wip/cmake branch of qtbase >>> to dev, soon™ (this week or next week). >>> >>> This is mostly a heads up email, so that it doesn't come as a total >>> surprise. >>> >>> How this affects people: >>> >>> 1) The qmake Coin builds are still there and continue to work. >>> >>> 2) Soon after the merge, a qt5.git change will land which will add a few >>> more qtbase Coin configurations which will build qtbase with CMake. >>> >>> 3) If these CMake Coin builds fail, developers of the respective changes >>> will have to adapt their changes to fix the CMake builds. >>> >>> 3.1) Most of these fixes can probably be done automatically by running the >>> magical pro2cmake.py script on the build system parts you changed. >>> >>> 4) The CMake port in not yet complete. >>> >>> 4.1) Not all tests are passing the test phase yet, that's why Coin ignores >>> test phase errors and will always say that test phase passed successfully. >>> The important part is that tests *build* successfully. >>> >>> >>> Preliminary tests showed that nothing breaks in Coin as a result of the >>> merge. >>> >>> >>> The current merge diff is at: >>> https://codereview.qt-project.org/c/qt/qtbase/+/282101 >>> >>> README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake >>> Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide >>> >>> Regards, >>> Alexandru. >> >> ___ >> 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] Heads up: Merge of qtbase/wip/cmake to qtbase/dev soon
Great! Thanks for the heads up! Tor Arne > On 11 Feb 2020, at 16:17, Alexandru Croitor wrote: > > Hi, > > Short PSA. > > The merge of wip/cmake to dev is done. > > I'm enabling enforcing CMake builds in dev branch. CMake build phase will > have to pass , tests can still fail and it won't fail integrations. > > In case some build system .pro change sneaks in between the merge and the > enabling of enforcing CMake Coin, all dev integrations will fail for a bit. > I'll fix that up. > > But afterwards, regeneration of the CMake projects will be the responsibility > of the person changing the .pro / .pri / .qrc / configure.json file. > If you don't know how to do that, you can come to freenode #qt-cmake for help. > > > Just in case: > > README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake > Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide > > > Regards, > > Alexandru. > >> On 3. Feb 2020, at 14:52, Alexandru Croitor wrote: >> >> Hi, >> >> The Qt CMake Port team would like to merge the wip/cmake branch of qtbase to >> dev, soon™ (this week or next week). >> >> This is mostly a heads up email, so that it doesn't come as a total surprise. >> >> How this affects people: >> >> 1) The qmake Coin builds are still there and continue to work. >> >> 2) Soon after the merge, a qt5.git change will land which will add a few >> more qtbase Coin configurations which will build qtbase with CMake. >> >> 3) If these CMake Coin builds fail, developers of the respective changes >> will have to adapt their changes to fix the CMake builds. >> >> 3.1) Most of these fixes can probably be done automatically by running the >> magical pro2cmake.py script on the build system parts you changed. >> >> 4) The CMake port in not yet complete. >> >> 4.1) Not all tests are passing the test phase yet, that's why Coin ignores >> test phase errors and will always say that test phase passed successfully. >> The important part is that tests *build* successfully. >> >> >> Preliminary tests showed that nothing breaks in Coin as a result of the >> merge. >> >> >> The current merge diff is at: >> https://codereview.qt-project.org/c/qt/qtbase/+/282101 >> >> README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake >> Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide >> >> Regards, >> Alexandru. > > ___ > 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] Heads up: Merge of qtbase/wip/cmake to qtbase/dev soon
Hi, Short PSA. The merge of wip/cmake to dev is done. I'm enabling enforcing CMake builds in dev branch. CMake build phase will have to pass , tests can still fail and it won't fail integrations. In case some build system .pro change sneaks in between the merge and the enabling of enforcing CMake Coin, all dev integrations will fail for a bit. I'll fix that up. But afterwards, regeneration of the CMake projects will be the responsibility of the person changing the .pro / .pri / .qrc / configure.json file. If you don't know how to do that, you can come to freenode #qt-cmake for help. Just in case: README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide Regards, Alexandru. > On 3. Feb 2020, at 14:52, Alexandru Croitor wrote: > > Hi, > > The Qt CMake Port team would like to merge the wip/cmake branch of qtbase to > dev, soon™ (this week or next week). > > This is mostly a heads up email, so that it doesn't come as a total surprise. > > How this affects people: > > 1) The qmake Coin builds are still there and continue to work. > > 2) Soon after the merge, a qt5.git change will land which will add a few more > qtbase Coin configurations which will build qtbase with CMake. > > 3) If these CMake Coin builds fail, developers of the respective changes will > have to adapt their changes to fix the CMake builds. > > 3.1) Most of these fixes can probably be done automatically by running the > magical pro2cmake.py script on the build system parts you changed. > > 4) The CMake port in not yet complete. > > 4.1) Not all tests are passing the test phase yet, that's why Coin ignores > test phase errors and will always say that test phase passed successfully. > The important part is that tests *build* successfully. > > > Preliminary tests showed that nothing breaks in Coin as a result of the merge. > > > The current merge diff is at: > https://codereview.qt-project.org/c/qt/qtbase/+/282101 > > README is at: https://github.com/qt/qtbase/tree/wip/cmake/cmake > Guide is at: https://wiki.qt.io/CMake_Port/Porting_Guide > > Regards, > Alexandru. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
I want to summarize intermediate results of the discussion and return it back to the track. Subject: using smart pointers in the API. Good idea. Better to use than not because of automatic lifetime management, explicit ownership semantics, and code base maintainability is simpler. However, it doesn’t mean that this is a mandatory choice for all API, just a recommended way so far. Subject: standard smart pointers vs. Qtish wrappers. In general, people want to use standard smart pointers. There are a few main reasons: std-things are already in Qt API, this is a part of C++ language standard, it requires almost no maintainability, people outside of Qt ecosystem most likely get used to standard smart pointers for nine years. We should also move Qt smart pointers to Qt5Compat module. The destiny of QPointer is not well defined so far. Subject: raw pointers for passing mandatory parameters vs. using references. Allow both approaches, recommend using references (and/or smart pointers) when acceptable. Not too many arguments collected here, just try to make Qt API more modern. There are a few irrelevant discussions. Start a new thread if you want to continue discussing them, please. Irrelevant subject: smart pointers vs. parent-child lifetime management model. It’s too fragile to touch in Qt6. Adding smart pointers around is questionable solution, it’s unclear whether it worth doing or not. Having two different but coupled mechanisms for lifetime management is not such a good idea. Irrelevant subject: something about Qt containers. On 1/31/20 11:07 AM, Vitaly Fanaskov wrote: > Hello everyone, > > We’ve been discussing for a while how Qt6 API can be improved with using > smart pointers. Recently we came into some conclusions and want to > discuss them with the community. > > Smart pointers are for sure much better to use than raw pointers for > many reasons. They manage lifetime automatically, show ownership > semantic, and make code safer. It’s planned to officially recommend them > to use in Qt6 API instead of raw pointers whenever this is possible. For > sure, it should only be a choice for newly designed API. > > But how to use them in the API and which way is preferable is still > unclear. There are two main options we have: > > 1) Use std::* smart pointers as-is. > > 2) Add Qt-style wrappers around std::* smart pointers and move old > implementations of Qt smart pointers to the Qt5Compact module. > > Both options have pros and cons. It would be useful to hear your > thoughts on it. It’s worth mentioning that some other options, like > using Qt smart pointers as-is, were also discussed. They were found less > suitable, but feel free to share your opinion if you disagree. > > Another thing to discuss is whether we should use raw pointers in the > API at all or not. There are a few options again: > > 1) Yes > > 2) No. Use “modern” approaches instead (pass mandatory dependencies by > either reference or const reference when using smart pointers makes no > sense, use something optional-like or tuples to return extra data from > functions, and so on) > > 3) Mix 1 and 2. > > There are pros and cons for all options. Share your opinion once again, > please. > > If there are any related things to discuss, let’s do that in this thread. > -- Best Regards, Fanaskov Vitaly Senior Software Engineer The Qt Company / Qt Quick and Widgets Team ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Great! Hopefully the remaining steps towards alpha go nicely. There are quite a few items not yet listed at: https://wiki.qt.io/New_Features_in_Qt_5.15 The new feature highlight is valuable for users, so please lift a few of the key items for each module into the list. Think what are the most important items to tell our users. We should have more content in place before the alpha, and finalize this before the first beta release. Yours, Tuukka On 11.2.2020, 11.12, "Development on behalf of Volker Hilsheimer" wrote: > On 10 Feb 2020, at 13:44, Jani Heikkinen wrote: > > Hi all, > > It seems that there is still some work needed to finalize deprecations and replacement for Qt 5.15 > > We had some discussion here in Qt Company and based on that I propose: > > - Let's put Alpha out after this header view feature is in. HeaderView change merged this morning: https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170 so we should be good to go with the Alpha. Cheers, Volker > - Let's agree these deprecations can be done still even the FF is in effect. But let's try to finalize deprecations and replacements as soon as possible. Blocking Alpha until all these are in doesn't make sense at this point anymore. > - Before Beta1 these deprecations needs approval of module maintainer > - And after Beta1 adding new deprecations needs Lars's approval > > That should bring us enough flexibility in this special situation without compromising or risking the Qt 5.15 release schedule too much. > > br, > jani > > > > >> -Original Message- >> From: Development On Behalf Of >> Jani Heikkinen >> Sent: torstai 6. helmikuuta 2020 10.03 >> To: Mitch Curtis ; Lars Knoll ; Yulong >> Bai >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >>> -Original Message- >>> From: Mitch Curtis >>> Sent: keskiviikko 5. helmikuuta 2020 15.40 >>> To: Jani Heikkinen ; Lars Knoll >>> ; Yulong Bai >>> Cc: Volker Hilsheimer ; Qt development >>> mailing list ; releas...@qt-project.org >>> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature >>> Freeze is in effect now >>> >>> >>> Hi Jani. >>> >>> - It's a vital part of creating a table in Qt Quick, and something >>> that is non- trivial for a good chunk of users to implement themselves. >>> - I think you and Lars have already said it's low risk, which is true. >>> - I don't think this counts as justification, but.. it's been in the >>> works for a while, and we really shouldn't delay it any longer. >>> - I'm also confident we will be ready to merge it today. >> >> Hi, >> >> Ok, nice to hear it won't take that long to get this in. And based on all >> discussion related to this & qt5.15 overall let's take this in Qt 5.15. >> >> We have other issues delaying alpha packages as well so this won't be only >> thing delaying it 😃 Let's try to finalize alpha content during this week & get >> Alpha out during next one >> >> Br, >> Jani >> >> >> ___ >> 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 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] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> On 10 Feb 2020, at 13:44, Jani Heikkinen wrote: > > Hi all, > > It seems that there is still some work needed to finalize deprecations and > replacement for Qt 5.15 > > We had some discussion here in Qt Company and based on that I propose: > > - Let's put Alpha out after this header view feature is in. HeaderView change merged this morning: https://codereview.qt-project.org/c/qt/qtquickcontrols2/+/270170 so we should be good to go with the Alpha. Cheers, Volker > - Let's agree these deprecations can be done still even the FF is in effect. > But let's try to finalize deprecations and replacements as soon as possible. > Blocking Alpha until all these are in doesn't make sense at this point > anymore. > - Before Beta1 these deprecations needs approval of module maintainer > - And after Beta1 adding new deprecations needs Lars's approval > > That should bring us enough flexibility in this special situation without > compromising or risking the Qt 5.15 release schedule too much. > > br, > jani > > > > >> -Original Message- >> From: Development On Behalf Of >> Jani Heikkinen >> Sent: torstai 6. helmikuuta 2020 10.03 >> To: Mitch Curtis ; Lars Knoll ; Yulong >> Bai >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >>> -Original Message- >>> From: Mitch Curtis >>> Sent: keskiviikko 5. helmikuuta 2020 15.40 >>> To: Jani Heikkinen ; Lars Knoll >>> ; Yulong Bai >>> Cc: Volker Hilsheimer ; Qt development >>> mailing list ; releas...@qt-project.org >>> Subject: RE: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature >>> Freeze is in effect now >>> >>> >>> Hi Jani. >>> >>> - It's a vital part of creating a table in Qt Quick, and something >>> that is non- trivial for a good chunk of users to implement themselves. >>> - I think you and Lars have already said it's low risk, which is true. >>> - I don't think this counts as justification, but.. it's been in the >>> works for a while, and we really shouldn't delay it any longer. >>> - I'm also confident we will be ready to merge it today. >> >> Hi, >> >> Ok, nice to hear it won't take that long to get this in. And based on all >> discussion related to this & qt5.15 overall let's take this in Qt 5.15. >> >> We have other issues delaying alpha packages as well so this won't be only >> thing delaying it 😃 Let's try to finalize alpha content during this week & >> get >> Alpha out during next one >> >> Br, >> Jani >> >> >> ___ >> 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 mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
