Qt Modules' Maturity Level

You may have wondered if you have ever submitted a bug report to Qt, why some reports are acted quickly upon and others take some time. However, I think it should come as no surprise to you that this is mostly a human factor: if your report catches someone who knows that particular codebase well -- and, of course, has the time for it -- it will be acted upon fast, even if it’s a lower priority like P3. If you however submit a report for an area of code for which the knowledge is thinly spread, this will take some time to get fixed. And if you submit a report for something which is deprecated, like QHttp or Qt3Support, chances are the bug will never be fixed.

With that in mind, and with Modularisation coming, we took a serious look at how much we still know about the Qt codebase in each module. In doing this exercise, we also want to point out which functionality we have in Qt that we really don’t want people to use anymore, where help is needed and where we are quite happy with the code.

As such we have created a summary list of where each module currently sits. We are aiming to use the list in the future as part of the Qt Open Governance, and it is called the Module Maturity Level.

The Levels

We have come up with five different levels in a ladder, plus an auxiliary stage. They are, in the order from most active to least active:

Active

• Module or functionality is being heavily worked on, changing rapidly
• New features are to be expected
• Fast bug response time
• Maintainer encourages and gladly accepts new code and new bug fixes

Maintained

• P0, P1 and P2 bugs are being fixed
• Most features for this codebase are done (see below)
• New features might be added
• Maintainer accepts new code and new bug fixes

Done

• Maintaining stability is the most important objective for the maintainer
• Maintainer must ensure code "works" (e.g. compiles, passes tests, etc.)
• Work will not be performed that adds new features or improves performance
• P0 and P1 bugs are being fixed
• Contributions that aren't related to P0 and P1 bug reports may be reluctantly accepted by the maintainer

Deprecated

• Marked as deprecated by the current maintainer
• No new code or bug fixes (except for P0s), with very few special exceptions
• Code should compile and efforts to maintain it that way should be reasonable
• Module or code will be eventually removed (Qt source and binary compatibility guidelines apply)

Removed

• Module or functionality has moved beyond deprecation
• The scope of the code is judged irrelevant, or better functionality exists elsewhere in Qt
• Module or code in the Removed state cannot be brought back into Qt

New Maintainer Required (auxiliary)

This is an auxiliary state usually attached to a codebase in "Done" state (but it could happen in others), indicating that the code has value and should remain in Qt, but there is no current maintainer for it. If this state is attached to a codebase, it means the Qt community is actively looking for and encouraging a contributor to step up and take on the responsibilities of maintaining this code. If no maintainer can be located, depending on the case, the codebase might move into Deprecated or Removed state.

Affecting the levels and Open Governance

It should be understood that the maturity level of a given codebase is a result of the actual code itself and the community working on it. The combination of the two is what dictates a module's level. That means, on one hand, that the community can organise itself to change the level a particular module, subsystem, feature or port is in, bringing it up or down the ladder. It can be a conscious decision by the group to say that a particular code has reached feature-completion and shouldn’t be worked on anymore. And circumstances may change, with new talent coming into the project, when the community may decide that it wants to do some work in code that was otherwise considered done.

On the other hand, there’s a limit to how far this can go: the intent behind the code may simply not lend itself to being extended. For example, it doesn’t make sense to add new features to Qt3Support. That module exists for one particular reason, which is to support the porting of Qt3 applications and, since Qt 3 itself isn’t getting new features, neither should this module. At the same time, an existing codebase has its stability requirements and these don’t change at the will of the community: adding new features or performance improvements may be possible, but not at the expense of the quality.

This is all personified in the maintainer of the functionality: one person to make the final call. Everyone else working in the community simply should be supporting this person, who is ultimately responsible for the quality, stability, features, requirements, etc. With that responsibility comes the right to make a final decision whether a particular contribution should be allowed in or not. This maintainer should compare the objective of the contribution to the overall maturity of the code he/she is responsible for and make a judgement on whether it’s supporting those goals.

If a contributor wants to raise the level of a subsystem towards a more active one, this contributor can volunteer to become the new maintainer of that particular section of the code. Becoming a maintainer means this person acquires the rights and responsibilities that go along: approving new types of submission, setting new goals, and also ensuring that the quality requirements (which already existed) continue to be met. And in the spirit of Open Governance, this person can be of any origin and background: the company this person works for matters little. What matters is that this person has the capability to do the job right and has shown that much (this may require that the employer support the activity, but that's a different story).

Next steps

These levels should be present in the bug reporting tools and in the documentation. Developers should be able to quickly find out what the situation is, especially if they are using API which is no longer recommended. The changes to JIRA and the doc will happen soon to support these notices.

In addition to coming up with this list, we have made an initial assignment of the Levels to the current Qt codebase, based on what the Qt team inside Nokia is currently working and our perception of the current state. I'll publish the results of that assessment in a few days.