Hey all, I have a few thoughts on open governance that I'd like to share. It's somewhat of a brain-dump, and a bit long to read, so bear with me :)
Current situation ================== The way things work today the authoritative Qt repository lives inside Nokia. All the Nokia-employed Qt developers commit to this repository either directly or though a staging repository which gets automatically integrated by our CI system. The repository is then synced out to the public on gitorious.org, where we have the merge-request mechanism to allow people to contribute from the outside. Contributions are integrated by Nokia-employed Qt developers by submitting the contribution though the same internal staging repositories as we use for our day-to-day development. The issues =========== The problem with the current situation is that it does not scale. Internal developers who go though the staging branches have to wait up to a day to get feedback on whether their commit built on platform X, or broke any tests on platform Y, sometimes more. External contributors have a similar problem, waiting days, weeks, or even months to get feedback on their merge-requests. High level solution ==================== To me Open Governance is not only about making Qt development more open, but also about using the opportunity to fix both these issues in one go. That starts with reversing the whole situation. The authoritative Qt repository has to live on the outside. Nokia will then use the public repository as a basis to productize Qt for devices and customers -- so the sync happens the other way, so to speak. Next we need to bridge the gap between how internal and external developers contribute code. We should all go though the same system and process, whatever that is (more on that later). This will force us to design a process that scales (as we will be eating our own dogfood), as well as level the playing field between Nokia-employed and other contributors. Finally we need to introduce a lot more automation in our process, so that our precious human reviewer and integration cycles are spent only on patches of high quality, with a high likelihood of passing the final quality gates of going into Qt. The modularization of Qt and having a set of trusted maintainers are two other key components in making the patch inflow process scale -- even when used by every single developer and for every single change. A possible patch workflow ========================== Please refer to the following diagram for the high level overview of the system: https://docs1.google.com/drawings/edit?id=14I_KRZeYtlRhETlrL1vjbaT6sI7xeN4-yOFyUwWoCLg&hl=en The basis ---------- The basis of the system is an authoritative Qt repository that lives in the public. Developers then clone and pull in new changes from this repository as part of their workflow. The review system ------------------- Once a change is ready for integration the developer submits the change (A) to the Review System. The review system should facilitate discussion about the change, providing features such as line by line commenting, context expansion, allowing updates to a change (based on feedback) and diffing between version of a change. The early warning system ------------------------- Once a new review is created or an old review has been updated the Early Warning System kicks in, by watching for new reviews to process (B). This system is basically a collection of bots that will run a wide array of tests on the patch. The crucial part about these tests is that they should all be quick to run, 5-10 minutes or perhaps even less. The idea is not to catch all errors, but to get immediate/early feedback on a patch. This means we'll have to compromise, for example do incremental builds, or run only the auto-tests directly affected by the change. But this is okey, as any false positives (allowing a bad change though) will be caught later on. Some ideas for tests: - Check coding style - Check for spelling errors - Build the patch against HEAD on various platforms - Run affected auto-tests - If the patch contains a new test, run the test before applying the code change, to verify that the test actually fails without the patch - Check that the commit message conforms to the template - Check that there's only one author in the patch-set The bots compromising this Early Warning System may live in various places/companies and run as part of various CI-systems -- the idea is that whoever has some hardware cycles to spare can build a bot to check something cool and contribute this to the distributed net of EWS bots. While the main idea of the EWS is quick feedback, you may have bots that take a little longer to run, for example compiling for embedded platforms, but that you still want to include in an early warning system. This could be solved by having the quick bots automatically jump on any new review, while the slow ones would have to be summoned in the review, similar to how you would CC a reviewer that you know has expertise in the area of the patch. Each bout would report back to the review system (C), giving the human reviewers an overview of the patch's status at a glance before actually looking at the code. The point is to weed out problems that can be caught by bots before human eyes look at the patch. A similar system is already in use in the WebKit project. See: - http://webkit-commit-queue.appspot.com/ for EWS status - https://bugs.webkit.org/show_bug.cgi?id=49200 for results reporting - https://webkit-commit-queue.appspot.com/status-bubble/73271 The integration system ------------------------- Once a review has been okeyed by one or more reviewers (depending on policy), the change goes into the next step -- integration. This is tooled by an integration system that keeps track of all the reviews that are ready to be integrated (D). In the governance model we've discussed so far we have component maintainers or lieutenants, and these would then use the integration system to integrate changes for "their" component into the main codeline. The system would list only relevant reviews for the given maintainer, and allow the maintainer to choose an arbitrary set of reviews (patches) to batch together for an integration run. Something like the UI of GitHub's fork queue: - https://github.com/blog/270-the-fork-queue Nice features to have are for example immediate feedback on whether the patch applies to HEAD of the Qt repository, or if the chosen set of patches apply in sequence. The UI would possibly let you choose a set of patches, re-order them until they apply cleanly, and then kick of an integration run (E). The quality gate ------------------- The quality gate is the part that takes the batched up set of changes and runs it through a clean compile on a wide array of platforms, runs the full set of tests, etc. The integration branch is rebased on top of HEAD. If an integration branch passes all these tests it's then merged into the main codeline. If the branch does not pass the result is fed back to the integration system (F), where the integrator will be able to inspect the failures and re-decide which changes/reviews to batch up for a new integration run. He or she may for example notice that the failure is obviously caused by one of the 10 changes, so the offending change is left out of the next batch. The quality gate also reports back to the review system (possibly though the integration system), if the failure can be pinpointed to a specific review (G). Action points ============== Now, this is all just a vision at this point, so if this matches other people's ideas of a well working process we'll have to sit down and figure out how we can achieve something like this with the currently available tools, or if we need to pay someone to build these tools for us. The components do not have to live together or be part of the same "product", we just need them to integrate. There are a few constants/constraints: - We use JIRA, there's no plan to change that - We need a contribution agreement, there's no plan to change that Apart from that (as far as I know) we should brainstorm. What do you guys think? Tor Arne _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
