[Development] How to create new Qt modules or tools

[henry.haverinen at nokia.com]

Hi all, 

I wrote:
> > 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.

I added a new section for moving existing projects. This needs review: http://bit.ly/tQkhkT
 
We have previously moved some new projects into Qt Add-On modules directly, so I added this possibility to the wiki too, for mature and established existing projects. Does this make sense?

I wrote:
> > 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.
Laszlo wrote:
> Could you please document it on the relevant wikipage ?

I added this to the playground wiki.
 
> 1) Build and software testing service

I think this question is still being discussed here, so I just added a placeholder section: http://bit.ly/uywbNO

Laszlo wrote:
> 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.

I think plain common sense or sane consensus goes a long way, but for modules that may become Qt Essentials there is a requirement to be compatible with all Qt's licensing options.
 
Laszlo wrote:
> 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 ?

Good points - to me it seems obvious that the natural maintainer of the freshly proposed module needs to become a Qt Maintainer for that module, if that module is moved to Qt,   and this could to be decided on the mailing list along with the existing process.   

> 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. :)
> 

It's important that all contributions to the playground project happen under the contribution agreement, so to my understanding this means that the same Gerrit-based coding workflow needs to be used. I think there is a way to self-approve patches in Gerrit, which should be fine for Playground projects.

Best regards,
Henry