The Qt Project was launched in October
2011 to foster the open development of the Qt toolkit. Qt is the underlying
framework used by KDE, of course, so Akademy attendees are understandably
interested in the status and progress of the Qt Project. Thiago Macieira
provided that update in a surprisingly well-attended keynote—surprising
because it was early on
the day after a social event that stretched into the wee hours.
The Qt Project
The Qt Project is based on four principles, Macieira said: fairness,
inclusiveness, transparency, and meritocracy. Fairness means that the
project is open to
everyone, while inclusiveness means that people can just start participating as there are no barriers in place
required. Transparency covers the decision-making process which is
completely open. Discussions happen on the mailing list, whose
participants ultimately make any decisions. When discussion takes place
elsewhere, it needs to be posted to the list for others to review and
comment on. Finally, a meritocracy means that contributors who have "shown
their skills and dedication" are given commit rights, and are the ones who
get to make the decisions for the project. That way, the most experienced
people get the most deciding power, he said.
The project has seen quite a bit of activity in the eight months it has
existed. Over that period, there have been 18,000 commits to the code
base, with an average of 412 per week. There were some dips in the graph
that he showed, for Christmas, Easter, Norwegian national day, and one that
he called "Elop". The latter correlated with Nokia CEO Stephen Elop's
statements that have caused concern about the future of Qt within the
company. When an
audience member suggested banning Christmas to increase productivity,
Macieira chuckled and said that banning Elop would be more effective.
Commit numbers do not show the whole story, though. To get a sense for the
community that is coming together around the project, Macieira also looked
at how many different people are contributing. Over the eight months, 481
different email addresses were used for contributions—averaging 140
different email addresses per week. There are some
more than one address, of course, but those numbers give an idea of the
number of contributors to the project.
Macieira put up a flowchart describing how to contribute to
the project. It looked relatively complex, with lots of "ladders and
contributing is actually fairly straightforward, he said. He pointed to the project wiki for
information on what is needed.
Code contributions are managed with the project's Gerrit code review instance.
Using the dashboard in that tool, one can see the status of current code
reviews, look at comments that have been made on the code, see the diffs
for the changes, and so on.
Code that has passed review from both humans and a bot that checks for
problems can then be staged from the Gerrit system. That moves the code
into an integration phase where it is merged into the mainline, compiled,
and tested. Two and a half hours later, contributors will get an email
with the results of the integration. It is "very simple", he said, and all
of the "eleven steps" from the flowchart "boil down" to this process.
KDE and Qt
Qt and KDE are "greater together", Macieira said, and he would like to see
the two communities merge into one large community. Qt provides the
libraries and framework, while KDE is building applications on top of
that. If KDE needs new features, they can be put into Qt as there is now a
"really nice way to make that happen". In the past, there had been
obstacles to moving functionality into Qt, but those are gone.
He gave several examples of people working on moving KDE functionality into
Qt. The KMimeType class has recently been added to Qt as QMimeType,
was essentially just moving and renaming the code. Other KDE classes have
required adaptations prior to moving into Qt, including KStandardDirs and
KTempDir. David Faure has been doing much of that
work, but he is not alone as Jon Layt has been working on moving the KDE
printing subsystem into Qt, while Richard Moore has been adding some of the
KDE encryption code (e.g. SSL sockets) to Qt.
Those are just three KDE developers who have started working in the
Qt upstream, Macieira said. There is a lot more code that could make the
move including things like KIO (KDE I/O), the KDE command-line parser, and
Beyond just code contributions, the project can use help in lots of areas.
One can be an advocate and help spread the word about the Qt Project.
Reporting bugs (and helping to fix some of them) is another area.
Documentation, translations, artwork, and so on also need people to work on
them; there is "a lot that you can do", Macieira said.
Developers can also start reviewing the code that is being proposed. It is
easy to get started with the code review system after creating an account.
What is really needed is "more people" and KDE is an obvious
source for some of those people. The two projects should "work more
closely to solve our objectives together", he concluded.
Asked about the filtering capabilities in the code review system to find
patches of interest for review, Macieira admitted that the search and
filtering functionality could use some work. There are ways to watch
specific projects by a regular expression match, but overall it lacks some
features that would be useful.
Another audience member asked about the statistics and, in particular,
whether they could be quantified based on whether the person considers
themselves a KDE developer. That is difficult to do, Macieira said,
because people wear multiple hats, but there is definitely value in doing so.
The last suggestion was for a joint KDE/Qt conference. Macieira
agreed that there would be "a lot of value in getting the two
communities together", but that it wouldn't work for this year. He would
like to see that happen next year, perhaps as part of the Qt Contributors
Summit. The summit is a hands-on working conference, without presentations
like Akademy has, he said, so a separate event might be the right
way to go.
After years of trying to turn Qt into a more open project with a
community orientation, it is nice to see that effort start to come to fruition.
Given the uncertainty in the future of Qt at Nokia, having an independent
project, with contributions from others outside of the company, will help
to ensure the future of the toolkit. Since KDE is one of the bigger users
of Qt, it only makes sense for the two projects to work closely
together—exactly what Macieira was advocating.
[ The author would like to thank KDE e.V. for travel assistance to Tallinn
for Akademy. ]
to post comments)