I joined The Qt Company's Oslo office on the autumn equinox of 2015. My boss was surprised that I fixed my first bug within my first week (and got the fix merged the next week): the project has some quite significant process that it normally takes folk time to learn their way around and the vast code-base usually takes some getting used to. But I'm used to those sorts of things, and found a bug that I was quickly able to deal with. I spent a lot of time early on doing code review, both as a way to make a difference before I got fully up to speed – I can spot mistakes even in an unfamiliar code-base; and things that look suspicious to me often tend to be hints at real problems, so folk (mostly) tolerated my ignorant questioning with good grace – and as a way to gain familiarity with the code-base, process and community dynamics.
Before long I gravitated
towards the
date-time code, which hadn't had much of anyone's attention for some time,
and set about fixing various parts of it. Getting dates and times mostly
right
is one of those things most programmers can do tolerably well, but
getting the details of time-zones and their transitions consistently right
is notoriously hard.
I had some practice in this field already, though. Sorting out the formatting
of dates and times (hence conversions from the internal representation to
textual ones suitable for display to users, and converting dates supplied as
text back again) involved me with the localisation (L10N) code (which commonly
provides the formats). While I've dabbled in other parts of the code-base
(particularly file-systems and the testing infrastructure), date, time,
time-zones and localisation (superficially straightforward
topics rendered tricky
by the whims of politicians) have remained my primary areas of expertise.
I was also one of the developers who kept merges and integrations going, until the project switched (in 2020) to cherry-picking back from the dev branch to release branches. We had automated systems to attempt merges (within each module) and integrations (updating the super-module to use current versions of each sub-module). When merges failed, the automated system created a code review and developers intervened to resolve the conflicts. If a merge or integration failed when tested by our continuous integration system, it was likewise left to developers to resolve within the code-review system. As an experienced git branch wrangler, I often got to resolve conflicts.
The Qt Project reviews all changes before they get accepted into the code-base; anyone willing to set up an account and accept the contributor license agreement can review any change proposed. Those whose reviews have been found to be constructive and useful get proposed by existing Approvers to be accepted as Approvers, meaning one can actually green-light a change, rather than just pointing out issues you see with it or saying that it looks OK to you. (Even after the change is approved, a cherry-pick of it onto the target branch has to, on diverse platforms and in diverse configurations, build and pass a vast battery of tests before it actually lands on the branch officially.) I was made an Approver after two thirds of a year – nominated for it by The Chief Maintainer, no less, and seconded by, among others, two prominent developers who don't work for the same company, one of whom is The Maintainer for the core, which contains the code I mostly work on.
The Qt Project is quite careful, when releasing new versions, to limit disruption for those upgrading to it. Great care is taken to ensure that code (as long as it only uses the public APIs) built against older versions will compile againgt newer ones without change (except in rare cases or at a major version upgrade, e.g. from Qt 5 to Qt 6) and to ensure that programs compiled against one version and linked against its shared libraries will run with the libraries of newer versions (within the same major version) and even with the libraries of older patch releases of the same minor version. That requires some fairly significant care and attention among reviewers and is reinforced by an API change review process. After seeing how that was done (it wasn't pretty and didn't make good use of our existing code-review facilities) I resolved to improve the process for such reviews. I wrote a small family of scripts, that now have a new home, to represent the changes in API as an (artificial) git commit, so that our code-review system will show what's changed in a more familiar way. These scripts first saw service for the Qt 5.7 release. I have repeatedly been thanked, since, by long-standing developers of Qt, for making the API change reviews significantly easier.
By the time the transition from Qt 5 to Qt 6 finally rolled around, I was familiar enough with the date-time, time-zone and localisation code to be able to see the major changes that could only be done (due to the API stability commitments described above) at a major version change. So while the world went into isolation against COVID-19, I was busy making the drastic changes (particularly to localisation of numbers) that would make Qt 6 significantly better in these areas.
In May 2023 I was officially recognised as the Maintainer of the date, time and locale code, becoming de jure what I have long been de facto.
You can learn more about The Qt Project from its home page; there's also a show-room of software using it.
Written by Eddy.