[Development] How to create new Qt modules or tools

[Laszlo Papp]

Hi Henry,

Thank you for your quick reply.

> The instructions were written with brand new projects in mind, but I agree we need to consider existing projects that move to Qt Project. The contribution agreement needs some special consideration here, so I'll work with Cristy on making that addition.
> For a new project, you could pick a name like 3D Audio, and then if it is moved into an actual module it could be called Qt 3D Audio.
> OpenAL is a special case because it is a 3rd party technology name. Whether using it in the module name falls under "fair use" would have to be checked with Qt Project Legal.

I was having the term idea according to the previous QtOpenGL. I have
just tried to go to their mailing lists, but they do not seem to load
here at the momment:
http://kcat.strangesoft.net/openal.html#about

Renaming to Qt3DAudio or something similar would not be a problem
either. I have been so far the only one contributing to the codebase.
I will patiently wait for Cristy's answer about it. :)

> In some cases we expect there to be several related playground projects, so it would not necessarily be fair to allocate a good name like "Qt Physics Engine" (just an example) for the first physics engine related playground activity. It needs to be given to the project that actually graduates into a real Qt module.
> Another reason for not using the Qt prefix is that we'd like to make sure the playground projects are not mistaken as actual Qt modules, because they don't have that status yet.

Could you please document it on the relevant wikipage ?

> The idea in this section of the wiki was to discuss the general spirit fit and technical fit of the project as a new Qt module on the mailing list, before including the module in Qt releases.  I don't know how detailed technical review and API review would be done for a module that has a long history (or might lack a part of the history in the repository).
> Lars and others, do you have comments on this?

I will wait for Lars and others, then. :)

I have further questions about the process in general:

1) Build and software testing service
Is there a build and software testing service provided for projects in
the Qt Playground repositories ? I have not seen any mentionings about
that so far. and it is an important question in my case, for instance.
I have been using CDash [1] for projects under the KDE umbrella. It is
possible as long as I use cmake as a build system in my project. I
think such a build and software testing service along with the
publishing of the build results would increase the QA of those
playground projects. I know there are such QA services for "final"
modules. I was just curious if those tools, providing the relevant
services, are available to Qt Playground projects or not. If not, are
there some other options ? It would be really nice if playground
projects could get such an attention. I am not willing to propose it
for all the projects there because I do not know the capacity, but at
least for projects and maintainers there who are interested in this
matter.

2) Requirement about third-party dependencies
In general, what is the requirement for third-party dependencies
regarding the new modules and tools ? Let me give a practical example.
QtOpenAL has been using a QALAbstractAudioDecoder interface at the
momment and there are various implementations of that interface (e.g.
"backends" like sndfile, libvorbisfile, flac, fluidsynth. Plans in the
future, like modplug, dumb, ffmpeg and so forth). Could you please
write something about third-party dependencies a bit more ? Are there
limitations for those or just a sane consensus ? It might be that new
modules or tools might try to bring new third-party dependencies in,
if possible.

3) Becoming a maintainer on this road
The playground project maintainer reaches the stage "Graduating from
the Playground". S/he would probably like to maintain this module
either in Qt essentials or as an add-on in a normal case. It means
that s/he would like become a maintainer. According to the Qt
Governance model [2]:
"...How to become a Maintainer
An Approver who makes a high level of contribution to the Project,
particularly to its strategic direction and long-term success, may be
nominated as a Maintainer by an existing Maintainer..."

How about this workflow in this case ? I guess some of the Qt
Playground project maintainers are not approver. Do they first need to
get nominated for this role, or can they ask the graduating from
playground directly without that process meanwhile becoming the
maintainer of the freshly proposed module ?

4) Review process
"...It's easy to kick off a new module or tool in the Qt project. With
the approval of a Qt Maintainer, you can request a new project to be
added to the Qt Playground area of codereview.qt-project.org..."

What does it mean precisely ? Does it mean that I have the same
workflow in playground as in the final stage or can I push directly to
my playground project as I can do that in KDE Playground ? I would
somewhat expect it is not that strict as the "final" Qt modules and it
is just a plus if someone takes the time with the review, but not an
expectation. I might be wrong with this because I am not that familiar
yet with this workflow. I think it would be a nice addition to get it
documented more thoroughly in order to avoid the confusion, or at
least make them explicitely very clear. :)

Thank you in advance!

Best Regards,
Laszlo Papp

[1] http://my.cdash.org/
[2] http://wiki.qt-project.org/The_Qt_Governance_Model