Hi All, Qt is the best multi platform library I have never used (compared to WxWidget, GTK, SDL...) always evolving to the right direction, with efficiency and robustness. The only point that was always looking like an old non evolving component was qmake. So when Qbs became a serious alternative (about 3 years ago) we migrate all projects (more that 20) to this well designed and efficient building solution, filling the lack of qmake. Qbs has drawbacks but is perfect for so many tasks (continuous integration, external compilers, rules...) and evolve quickly with well defined purposes. Now you want use to go back to an old and so bad solution as CMake. Sorry to say that but this is not a good decision and for the first time I buy and use Qt every year, I feel not confident with this decision since this is a real regression. No other decision that was taken was regression, this is the first one . I would accept if you had to choose between two good solutions and decide to keep only one because it's too expensive to maintain the both but here this is a rollback to an old and inefficient technology.
And I'm not mentioning the time and money we have spent to migrate to Qbs and that we will need to migrate back to qmake/Cmake. Really disappointed with this decision. Olivier PS : sorry for my english if not perfect. Le 07/11/2018 à 08:31, Lars Knoll a écrit : > Hi all, > > Let me follow up on this now that everybody had a bit time to digest things. > Hopefully, we can move the discussion into a constructive direction on how to > move forward. I’ll have to switch a bit between my Chief Maintainer and CTO > hat in the below, I hope that’s ok. > > It’s correct to state that Qbs has been developed fully by The Qt Company in > the past. Now we are in a situation, where The Qt Company has said that they > will not invest into the technology anymore in the long term. Fortunately > that doesn’t imply an immediate stop of all work. > > The Qt Company will be supporting Qbs for another year. This includes doing > one feature release that wraps up what has been developed so far some time in > Winter/Spring and also supporting it in Qt Creator for at least that time. > > I think this also gives us a chance to do a proper handover to the community > if we can find some people who are interested in helping with maintaining the > technology. From The Qt Company’s perspective, we’d be glad to help with this > transition effort. Let’s try to find out, what’s needed to make such a > handover a success > > From a qt-project perspective, I am happy to keep Qbs here and provide all > the infrastructure required. This includes hosting the code on codereview, > bug tracking through our Jira, testing in the CI system and having some > landing page/domain where people can find info on qbs. > > As long as we have a maintainer, I also do not see a larger problem in > keeping the Qbs support in Qt Creator. > > Of course, we don’t need to have a new maintainer immediately, we have some > time to see who would step up. But it would be great if we could find a new > maintainer (or several maintainers) during next year. > > Cheers, > Lars > >> On 31 Oct 2018, at 06:51, Richard Weickelt <rich...@weickelt.de> wrote: >> >> Dear all, >> >> on the Qt developer mailing list, Lars Knoll recently announced: >> >>> We have been developing Qbs over the last years, and as such are >>> committed to it for some more time. We are planning on another feature >>> release in the first quarter of next year and will support it in Qt >>> Creator for at least another year. Qbs is open source and if someone >>> wants to take over and develop it further let us know as well. I’d also >>> like to use this place to thank Christian and Jörg for all their great >>> work on Qbs (and of course also anybody else who contributed to it). >> Qbs is open source but the largest part of development has always been >> shouldered by The Qt Company and the decision processes have never been open >> and transparent. >> >> It would be great if the TQtC could clarify what is planned for the next >> feature release and why. I would be glad if the TQtC would spend the >> remaining resources on transitioning the Qbs project into a community >> ownership. I have no experience how a successful transition could look like. >> Therefore I am asking for role models. >> >> What I can think of, but I might be wrong: TQtC maintainers, please >> communicate upfront what you are going to do, how and why so that others can >> learn. Some questions, I think, we should clarify on the mailing list: >> >> - Can we define milestones for a successful transition and clarify what >> TQtC is willing to invest? >> - There were some companies using Qbs for their own projects [1]. Can we get >> committment from those? >> - Can we keep using TQtC infrastructure, domain wtc.? >> - How does the release process of Qbs work? >> - Are there parts in the codebase that make maintenance difficult and >> that could be simplified? Maybe parts duplicating Qt code that should >> be rebased onto Vanilla Qt? >> >> Thank You >> Richard Weickelt >> >> >> [1] >> https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0 > _______________________________________________ > Qbs mailing list > Qbs@qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs _______________________________________________ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs