[Qbs] Future of Qbs

olivier musse olivier.musse at sfr.fr
Wed Nov 7 10:23:51 CET 2018


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 <richard at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs





More information about the Qbs mailing list