[Development] Proposing new Qt Creator module: Qt Creator Solutions

[Mike Trahearn]

+1 for Jarek and for this module.

________________________________
From: Development <development-bounces at qt-project.org> on behalf of André Hartmann <aha_1980 at gmx.de>
Sent: Friday, December 1, 2023 4:00:07 PM
To: apoenitz <apoenitz at t-online.de>; Fabian Kosmale <fabian.kosmale at qt.io>
Cc: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions

Good morning,

for me both suggestions (first separate the code, then moving it to Qt)
sounds good to me.

+1

André

Am 30.11.23 um 23:00 schrieb apoenitz:
> On Thu, Nov 30, 2023 at 07:41:06PM +0000, Fabian Kosmale wrote:
>> Hi,
>>
>> I agree that it would be nice to properly separate Solutions (to enforce their
>> reusability, and to make it easier to include the module into other projects).
>>
>> I'm also convinced that Jarek would do a good job as the maintainer of the
>> module.
>>
>> I have however two questions:
>> 1. How this will affect packaging/releasing of QtCreator?
>
> In the current setup that's not affecting nor meant to be affecting anything
> like that at all, i.e. the main difference between libs/solution/tasktree and,
> say, src/plugins/git is that the former does not depend on anything outside Qt
> proper whereas the latter can and does depend on other items in Creator's
> src/plugins/* and other src/libs/* bits that cannot so eaily be split off in
> self-contained pieces.
>
> Once one libs/solution/* is considered reasonably complete and stable API-wise
> there may be a suggestion to move it over to Qt. Or not. (I don't think we need
> a QFakeVim in the end but I'd probably make that one of the "Solutions" at some
> time nevertheless.)
>
>> 2. Will the release cycle of the modle be coupled to Creator's release cycle?
>
> At least for now: As long as it's not upstreamed, yes.
>
> [The interesting granularity here would actually be individual solutions, i.e.
> currently "TaskTree", "Terminal", and "Spinner". I currently think that we
> shouldn't overengineer this by, say, having "Sub-component" maintainers, but
> given that the "Solutions" are by definition independent of each other _maybe_
> that's the way to go mid-term. The current proposal is basically to start with
> minimal bureacratic and maintenance overhead and see how far we get with that.]
>
> Andre'

--
Development mailing list
Development at qt-project.org
https://urldefense.com/v3/__https://lists.qt-project.org/listinfo/development__;!!Nbma_1s!pdSKCS9iRzlMa4W1QMk1lNxumacLe_AJmdgkkBWVK6_Uw58u_8rJ9yiiaT6iBtmNMjUC1w5LA8egglb8Ng$
Confidentiality Notice: This message (including attachments) is a private communication solely for use of the intended recipient(s). If you are not the intended recipient(s) or believe you received this message in error, notify the sender immediately and then delete this message. Any other use, retention, dissemination or copying is prohibited and may be a violation of law, including the Electronic Communication Privacy Act of 1986.   ­­
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231201/a7300c4e/attachment.htm>