- Qt Developer Days 2011 Munich
- Qt Contribution Process
Qt Developer Days 2011 Munich
Qt Contribution Process
Mark Hatch, Roland Krause and Justin Noel
Mark: Good afternoon, this is Mark Hatch from ICS, and I run the Qt business here for ICS, and today is ‘This Week in Qt’. This is a special one today. We are broadcasting from the Munich DevDays 2011, and with me today is Roland Krause who heads up our California office, and as usual Justin Noel, one of our lead engineers.
So today we are going to talk about the new Qt contribution process that was released here and was the big news at Qt DevDays. Justin, do you want to summarize what it is?
Justin: Yeah leading the roundup on Monday was the Qt Contributor Day, which tried to bring together all the people coming to Munich who wanted to contribute to Qt to talk about the new process and the new website, qt-project.org. To learn more about contributing to Qt, go to that website. Attendance was good. People were talking about libraries and what work needs to be done, and how they could actively contribute to Qt in a meaningful way.
M: So what happened to all the mailing lists and everything else?
J: Everything is now being moved over to qt-project.org. In fact, if you were on mailing lists from qt.nokia.com, there is now a new, more appropriate mailing list on qt-project.org, including the most important one which I think is developers at qt-project.org, which is going to have everybody; Nokians and third-parties and everybody who wants to work together as developers on Qt. You will see every discussion that everybody has to make Qt going forward.
M: Now, if you were on qt-interest, would you automatically get moved, or do you have to re-subscribe.
J: You have to move yourself to qt-project.org, so keep that in mind as mails ramp down on qt-interest. You are going to need to move.
M: Now is it qt-project.org or qtproject.org?
M: Ok good, I just want to make sure everybody is all set on where to go.
So how did they describe the process? If I was going to contribute, how would I go about that?
R: Well the big story about the new contribution model is that we are all equal peers at this point. So everyone from Nokia who is employed at Nokia and working on Qt, and all the third-party contributors, and all the people from the community now have the same rights and the same obligations in this process. And this is supported by a new code-review system which is a very nice tool named JIRA to submit merge requests, and for collaboration in general, but what it basically allows you to do is, you get an account and when you have been working on a certain feature or a bug fix, you make yourself known that you want to submit this bug fix through this JIRA tool, and a peer-review process sets in and maintainers and reviewers will look at your stuff and than approve it and it will get merged in. And the great thing about this process is that it’s the exact same process for the internal Nokia members of the Qt team as it is for outside contributors.
J: Yeah, so no more waiting around for a week after you hit that merge request button.
R: Absolutely not.
M: So how do you get on that review list? Obviously there is a hierarchy of contributors…
R: Yeah, as Lars outlined in his keynote presentation, there is a hierarchy level. There are basically contributors and it’s a meritocracy, meaning that by the merit that you acquire in this process, you move up in the ranks. At the very top of the list is the model of the benevolent dictator, which is Lars himself at this point. He is the one who has the tie-breaking, decision making authority, which will only be used in extremely rare cases.
R: Yes, I’m pretty convinced. At the regular level, everybody is a contributor. There are people who are at the next level who are reviewers. Contributors become reviewers at the point where they have acquired some expertise in a certain subject. Everybody will eventually, after regular contributions, be invited to become a reviewer. And then there are maintainers. There are certain modules. Now, Qt 5 is split up in a set of modules… base modules, networking modules and so on. And they are the main experts that have the dominant expertise, and they are the maintainers of a module, and they will then actually execute the merge.
J: It’s interesting about becoming a reviewer because even the lowly contributor all the way at the bottom can comment on anybody’s check-ins. So if you want to become an official reviewer, simply show your skills by commenting on patches as they go by, and if you give good comments you will be nominated to be an official approver.
M: So have they selected any of the maintainers yet, or have they announced any of them?
R: I have not heard that they have announced, but I am sure that they have selected them, yes.
M: Very interesting. So what does this mean for the release process? We are just about done with 4.8, and this process comes in with 5?
R: Yes, and what it means is essentially that Qt will follow the many other open-source projects that they are aiming for two releases per year. And those will be the dot 1, dot 2, dot 3 releases, so mainly feature releases and bug-fix releases that will not break compatibility. There is a big-picture road map. And per the meritocracy process, these roadmaps will be laid out likely during the Qt contributor’s summit that will be held yearly or twice a year.
M: So there is going to be 2 releases a year, and those become 5.1 and 5.2, presumably, or maybe 5.0 and 5.1… and how are they declared? Does Lars end up deciding that it’s done, that it’s cooked?
R: Yes, there will be a release date. During the contributor’s summit, there will be a projection as to how things are progressing and a feature set will be declared. A feature freeze will be declared at some point, and than a release stabilizes in a normal process as is commonplace in open-source projects.
J: And of course, the releases are based on “timed twice a year” but as is the case now, quality is first.
M: Right. Now, who’s doing the testing? How is the testing getting done? Have they addressed that?
J: They are currently opening up the testing system for everybody to use, just like the Nokians internally use them, so that you can add your own tests that will be tested continuously, and you also get notified as to exactly what tests you broke, just like any other contributor that previously worked at Nokia. It used to be for us that if you merge requested, and it broke an internal unit test, you never really got to see exactly what was going on. Maybe it was a bug or something like that.
R: That process is now completely transparent and QA was always a huge amount of contribution from the community. There are so many projects out there that are using the Qt libraries, and this has not changed. This entire model of that will not change, has not changed and we are anticipating that it’s going to contribute greatly to the stability and quality of the libraries.
M: So the fact that Nokia no longer has a hand on the button, the green button and the red button, shouldn’t worry anybody because the testing is still going on, on a daily or weekly basis.
R: Oh yeah, there is a continuous integration system in place, so all code contributions will be immediately checked for stability, but then there is the additional component of QA through the entire community.
M: So this sounds like a really exciting process, and it will be interesting to see how it unfolds over the next months, actually years. This will be the first real test in 2012.
Well great! Thank you Justin and Roland, it’s been a very informative session here on the contribution process, and we’ll see how it rolls out, but it sounds promising. Thank You.
R: Thank You.
J: Thank You. Greetings from Munich.