Re: [Qbs] Future of Qbs
Lars or anybody else from The QtCompany, I would like to follow up on this topic. > 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 Right now the Qt Company holds the ownership of the code base and all contributions have to pass the obligatory Qt CLA. The Qt Company has also clearly communicated that they would not support Qbs beyond 2019. That makes it very difficult to convince other parties to invest in it. It would be good if the Qbs project would be transferred to a widely trusted, non-personal, non-profit organization. The Linux foundation for instance might be a candidate we could try. Such an organization as backup would help the Qbs project to - gain trust among (industrial) customers - find sponsors - to get structural, organizational and maybe also technical support Thus, would the Qt Company be willing to: 1. transferring ownership of the code base and the brand Qbs to a non-personal non-profit entity? If yes, in which time frame? 2. re-license Qbs under a permissive open source license? Is Qbs even subjected to the agreement with the KDE Free Qt Foundation? 3. Sponsor the Qbs project, for instance by continue to pay for the domain qbs.io or by allowing Qt engineers to spend (limited) time on keeping Qbs working in QtCreator, doing code reviews to some extend in their work time? 4. provide technical infrastructure like JIRA, gerrit, hosting, at least for a transition period of 2 years even though ownership has been transferred? Thank you for your reply. Best regards Richard Weickelt ___ Qbs mailing list Qbs@qt-project.org https://lists.qt-project.org/listinfo/qbs
Re: [Qbs] Future of Qbs
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 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
Re: [Qbs] Future of Qbs
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 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
Re: [Qbs] Future of Qbs
Been thinking about the "why" this has deprecation has happened: -CMake has large user base -> As a result, CMake has a large corporate user base --> As a result, a lot of Qt Commercial users use CMake The Qt Company only asked commercial users their opinion, so the results are garbage. CMake did not win on technical merit, even Qt Company employees admit that. Imagine if, in the early days of Qt, Qt itself was announced as deprecated simply because more [corporate] users used Gtk/C? Where would we be today? Qbs hasn't seen much community contribution because it's state-of-the-art software that's functional. It's difficult to dive into and add features to state-of-the-art software simply because as non-authors of the code we don't have the vision and designs/plans for the project and where it's going (in the macro sense), let alone familiarity with the heart of the code base. Maintaining compilers/flags, fixing bugs, and adding incremental features, though? That can easily be achieved by the community... indefinitely. There haven't been community contributions to maintenance/etc of Qbs for one simple reason: there didn't need to be, Qt Company did it. Community software progresses forward from independent developers "scratching their own itch". You scratched our Qbs itch for us, then point out nobody contributes to Qbs. Why would we when it works fine (not only fine, but GOOD)? Qbs adoption never took off because you never defaulted to it, never took it out of "experimental" state. I was eyeing it for years, agreeing it was superior, ready and waiting to start using it as soon as Qt defaulted to it... and it appears many others were doing the same. Was Qbs not defaulted to because Qt Company was waiting for more users to start using it, while the users didn't use it because Qt Company never defaulted to it? LoL, cyclic dependency <3: You never gave Qbs a chance. I think in the long run a community-maintained Qbs could outgrow CMake, simply because Qbs is designed better (some CMake devs would change camps). [Incrementally] Copying what CMake does, but implementing with a better design, still adds value even though it partially reinvents the wheel. Take for example LibClang and all the [easily used] functionality it adds on top of GCC. Better design = more useful... even though Clang had to "reinvent the wheel". And besides, Qbs is already functioning, should have defaulted to it and the corporate users would have largely accepted it. Corporate users are usually the last ones to dive in and adopt EXPERIMENTAL software. And hell, if I was a corporate user right about now I'd place significantly less stock in any of Qt Company's "experimental" software... because it might just up and disappear at a whim. d3fault p.s. I don't care if qtbase uses CMake/QMake etc, since I don't maintain those projects. But for my own projects, I really want[ed] to use Qbs. The way you organized libs and apps and all that in Qbs was downright pleasant to navigate. ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
I just want to point something out, something that's not that visible on the blog post that it appeared at. In this post: http://blog.qt.io/blog/2017/12/07/qbs-1-10-released/ just a little less than a year ago, qbs was touted as the new Qt build tool. This isn't speculation, these are direct words from TQtC employee. Essentially: TQtC encouraged their customers to migrate, then, less than a year later, they deprecate it on dubious grounds essentially making this earlier post a lie. I have to ask: how is this helping Qt's business strategy? You've essentially wasted hour upon hours of your customers time and ignored it all at the drop of a hat. This is a direct breach of trust that potentially has severe financial consequences. On Wed, Oct 31, 2018 at 11:16 PM Jochen Becher wrote: > > Hello, > > the company I am working for was an early adopter of Qbs. We migrated > over hundred projects and components with several million lines of C++ > source code to it. Several teams are working with Qbs on a daily basis. > We are mostly satisfied with the current release and we will not move > away from this great build system. > > We are really disappointed by TQC deprecating Qbs. How much can we > trust that the same will not happen with QtCreator or some Qt modules > or platform support? > > But we will moderately invest into Qbs' future at least by improving > the integration into QtCreator and keeping Qbs on the level we need. > > Regards, > > Jochen 'gilead' Becher > > Author of QtCreator's ModelEditor plugin > > Head of 30 software developers who are happily use Qbs > > > > Am Mittwoch, den 31.10.2018, 06:51 +0100 schrieb Richard Weickelt: > > 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 > ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
Hello, the company I am working for was an early adopter of Qbs. We migrated over hundred projects and components with several million lines of C++ source code to it. Several teams are working with Qbs on a daily basis. We are mostly satisfied with the current release and we will not move away from this great build system. We are really disappointed by TQC deprecating Qbs. How much can we trust that the same will not happen with QtCreator or some Qt modules or platform support? But we will moderately invest into Qbs' future at least by improving the integration into QtCreator and keeping Qbs on the level we need. Regards, Jochen 'gilead' Becher Author of QtCreator's ModelEditor plugin Head of 30 software developers who are happily use Qbs Am Mittwoch, den 31.10.2018, 06:51 +0100 schrieb Richard Weickelt: > 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
Re: [Qbs] Future of Qbs
Not saying you should build Qt with it, I do see the point Thiago makes, but it looks like qbs is becoming a major point of even going Qt if we go by ppl's comments. Feels like you could extend support and see if it's feasible to switch to it a few years later. On Wed, Oct 31, 2018 at 4:41 PM NIkolai Marchenko wrote: > Thiago, Lars: can we please have another blog post asking for people to > voice their opinion on the matter? > it does seem like you are underestimting how much traction qbs has. > People in the comment section are saying they are porting their projects > to qbs left and right. > This is very far from "failed to gain traction" > More like: "finally gaining momentum" > > On Wed, Oct 31, 2018 at 4:35 PM Kari Oikarinen > wrote: > >> On 31.10.2018 15:26, Christian Gagneraud wrote: >> >> > PS: completely off-topic, has qt.io (aka the Qt Company) ever heard of >> > https everywhere [1]? >> > The Qt mailing list archive is currently serving plain HTTP over HTTPS >> > port [2]. And is redirecting http to https... >> > >> > [1] https://www.eff.org/https-everywhere >> > [2] http://lists.qt-project.org/ >> >> It's a new problem that popped up recently and IT should be onto fixing >> it now. >> >> -- >> Kari >> ___ >> 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
Re: [Qbs] Future of Qbs
Thiago, Lars: can we please have another blog post asking for people to voice their opinion on the matter? it does seem like you are underestimting how much traction qbs has. People in the comment section are saying they are porting their projects to qbs left and right. This is very far from "failed to gain traction" More like: "finally gaining momentum" On Wed, Oct 31, 2018 at 4:35 PM Kari Oikarinen wrote: > On 31.10.2018 15:26, Christian Gagneraud wrote: > > > PS: completely off-topic, has qt.io (aka the Qt Company) ever heard of > > https everywhere [1]? > > The Qt mailing list archive is currently serving plain HTTP over HTTPS > > port [2]. And is redirecting http to https... > > > > [1] https://www.eff.org/https-everywhere > > [2] http://lists.qt-project.org/ > > It's a new problem that popped up recently and IT should be onto fixing > it now. > > -- > Kari > ___ > 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
Re: [Qbs] Future of Qbs
On 31.10.2018 15:26, Christian Gagneraud wrote: > PS: completely off-topic, has qt.io (aka the Qt Company) ever heard of > https everywhere [1]? > The Qt mailing list archive is currently serving plain HTTP over HTTPS > port [2]. And is redirecting http to https... > > [1] https://www.eff.org/https-everywhere > [2] http://lists.qt-project.org/ It's a new problem that popped up recently and IT should be onto fixing it now. -- Kari ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
If there is any hope of qbs being developed further there needs to be a design philosophy document from current maintainer. On Wed, Oct 31, 2018 at 1:57 PM Timur Kristóf wrote: > On Wed, 2018-10-31 at 20:45 +1300, Christian Gagneraud wrote: > > > > > > 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 looks to me a bit early to make some plan, give people enough time > > to digest this. > > I'd like to know if the decision to obsolete Qbs is final, or is there > a chance that you guys might still change your mind? > > Taking a look at the blog bost I see a lot of salty comments coming > from Qbs users. > > Still, I'd be happy to continue using Qbs too, if it's maintained by > the community. Kudos to Richard for starting this thread. > > Best regards, > Tim > > ___ > 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
Re: [Qbs] Future of Qbs
On Wed, 2018-10-31 at 20:45 +1300, Christian Gagneraud wrote: > > > > 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 looks to me a bit early to make some plan, give people enough time > to digest this. I'd like to know if the decision to obsolete Qbs is final, or is there a chance that you guys might still change your mind? Taking a look at the blog bost I see a lot of salty comments coming from Qbs users. Still, I'd be happy to continue using Qbs too, if it's maintained by the community. Kudos to Richard for starting this thread. Best regards, Tim ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
I have added a new field to that table: "QBS used since" This is kind of relevant. If you've put your project in previously, please fill it On Wed, Oct 31, 2018 at 1:30 PM NIkolai Marchenko wrote: > I would like to remind in this thread that we have a list going to > hopefully change TQtC's image of qbs adoption. > Please post your qbs projects there: > https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0 > > On Wed, Oct 31, 2018 at 1:09 PM Christian Kandeler < > christian.kande...@qt.io> wrote: > >> On Wed, 31 Oct 2018 06:51:43 +0100 >> Richard Weickelt wrote: >> >> > It would be great if the TQtC could clarify what is planned for the next >> > feature release and why. >> >> That's easy: The release will simply contain everything that has been >> done since 1.12, i.e. all patches that have already landed in master and >> some that are almost finished (plus possible community contributions). The >> most noteworthy improvements will be job pools and proper Android support >> for Qt apps. >> >> > - How does the release process of Qbs work? >> >> It's not particularly involved. Source packages are created with git, >> the Windows binaries (including the chocolatey package) are built by >> qbs itself. There is a public docker image that automates this task; >> see https://doc.qt.io/qbs/building-qbs.html#building-release-packages. >> >> > - Are there parts in the codebase that make maintenance difficult and >> > that could be simplified? >> >> The module loader, which does the low-level part of resolving a project, >> is very complicated and brittle. Changes in that area typically pose the >> biggest challenge. The rest of the code, while not necessarily trivial, can >> be touched without fear of losing one's sanity. >> >> > Maybe parts duplicating Qt code that should >> > be rebased onto Vanilla Qt? >> >> Why would there be? >> >> >> Christian >> ___ >> 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
Re: [Qbs] Future of Qbs
I would like to remind in this thread that we have a list going to hopefully change TQtC's image of qbs adoption. Please post your qbs projects there: https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0 On Wed, Oct 31, 2018 at 1:09 PM Christian Kandeler wrote: > On Wed, 31 Oct 2018 06:51:43 +0100 > Richard Weickelt wrote: > > > It would be great if the TQtC could clarify what is planned for the next > > feature release and why. > > That's easy: The release will simply contain everything that has been done > since 1.12, i.e. all patches that have already landed in master and some > that are almost finished (plus possible community contributions). The most > noteworthy improvements will be job pools and proper Android support for Qt > apps. > > > - How does the release process of Qbs work? > > It's not particularly involved. Source packages are created with git, > the Windows binaries (including the chocolatey package) are built by > qbs itself. There is a public docker image that automates this task; > see https://doc.qt.io/qbs/building-qbs.html#building-release-packages. > > > - Are there parts in the codebase that make maintenance difficult and > > that could be simplified? > > The module loader, which does the low-level part of resolving a project, > is very complicated and brittle. Changes in that area typically pose the > biggest challenge. The rest of the code, while not necessarily trivial, can > be touched without fear of losing one's sanity. > > > Maybe parts duplicating Qt code that should > > be rebased onto Vanilla Qt? > > Why would there be? > > > Christian > ___ > 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
Re: [Qbs] Future of Qbs
On Wed, 31 Oct 2018 06:51:43 +0100 Richard Weickelt wrote: > It would be great if the TQtC could clarify what is planned for the next > feature release and why. That's easy: The release will simply contain everything that has been done since 1.12, i.e. all patches that have already landed in master and some that are almost finished (plus possible community contributions). The most noteworthy improvements will be job pools and proper Android support for Qt apps. > - How does the release process of Qbs work? It's not particularly involved. Source packages are created with git, the Windows binaries (including the chocolatey package) are built by qbs itself. There is a public docker image that automates this task; see https://doc.qt.io/qbs/building-qbs.html#building-release-packages. > - Are there parts in the codebase that make maintenance difficult and > that could be simplified? The module loader, which does the low-level part of resolving a project, is very complicated and brittle. Changes in that area typically pose the biggest challenge. The rest of the code, while not necessarily trivial, can be touched without fear of losing one's sanity. > Maybe parts duplicating Qt code that should > be rebased onto Vanilla Qt? Why would there be? Christian ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
On Wed, 31 Oct 2018 at 18:51, Richard Weickelt 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 looks to me a bit early to make some plan, give people enough time to digest this. Chris ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
> The main point of doing this is to have a new maintainer for the project > after the last > release by TQtC. I started investigation in Xcode generator (but help is > welcome), I’ll > spent a bit time on experimenting with clang on Windows. People willing to > contribute, > please do so. We're also willing to contribute to an open-sourced Qbs (to some extent, we already did so in the past). We could take care of Qbs integration in Qt Creator and also could help in fixing issues. > Back to the original post, we will need some coordination. This mailing list? Sounds good to me. Thomas ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Future of Qbs
Richard, thank you for writing this post. I was thinking of doing it myself, but I never was good at writing long letters=) Anyway, I would like to suggest that people who interested in QBS start contributing in it now. We have half a year to get familiar with the codebase while Christian Kandeler is still here. The main point of doing this is to have a new maintainer for the project after the last release by TQtC. I started investigation in Xcode generator (but help is welcome), I’ll spent a bit time on experimenting with clang on Windows. People willing to contribute, please do so. Back to the original post, we will need some coordination. This mailing list? > 31 окт. 2018 г., в 6:51, Richard Weickelt написал(а): > > 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
Re: [Qbs] Future of Qbs
As part of this transition I believe Qbs should be relicensed to MIT so that the community can be independent of the original creator and do what it wants. Il giorno mer 31 ott 2018 alle ore 06:51 Richard Weickelt < rich...@weickelt.de> ha scritto: > 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 > -- https://liri.io ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
