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

[André Hartmann]

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'