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@qt-project.org
https://lists.qt-project.org/listinfo/development
