Recently I blogged about how we are keen to improve patch review in Ubuntu in the 10.10 cycle. Today we are in a position where we have a large collection of fantastic contributions that need reviewing, even if that review feedback is that the patch no longer applies and needs work.
I believe part of the problem here is that reviewing patches is just too hard. At the Ubuntu Global Jam on Friday I was talking this through with a few people and I started drilling on the idea of a desktop tool that improves viability on patch contributions and automates much of the work involved. I believe this tool could greatly open up the world of patch review to more people.
This morning I decided to formulate my thoughts a little better and draw up some mock-ups of a the app which I am nicknaming Mergimus. Unfortunately, I don’t have the time to commit to writing this app, so I wanted to blog the design as an opportunity to kick off some discussion and to maybe inspire some of you good folks to pick up the design and start building it. Let me explain my thinking…
The basic idea with Mergimus is that you are often interested in and have a core competency and awareness of specific projects and you want viability on the patches and merge proposals that are part of those projects. When you fire up Mergimus you would see the patch view screen:
In the left box is a treeview with a list of projects that you are interested in: each of these are source packages in Ubuntu. You can add a new project to the list by clicking the button underneath the tree view and a dialog box will pop up where you can enter a project name, and a list of matching projects will appear, and when you double click one it will add it to the main treeview.
When you click on a project, the box to the right displays a list of the patches and merge proposals available for that project. This immediately provides a TODO list of things that the user can work on, solving the first problem many prospective contributors have – “what can I work on?“. If the user wants to see all patches and merge proposals for all the projects they are interested in, they can click the
All option at the top of the tree view.
When the user decides that they want to work on a given patch or merge proposal, they double click it and the view changes to the Review View:
This view has a series of key components. First, at the top of the view we see the Currently Reviewing label and a breadcrumb trail – clicking each item in the trail will open the relevant Launchpad project page in your web browser.
On the bottom-right of the view you can see a treeview with a list of changed files that are part of the patch or merge proposal. Clicking on a file will load it into the top part of the main body of the view which is a text editor. Inside the text editor a diff will be shown with the differences between the patch and the source package’s file. Each diffed file loads in a different tab.
Above the file listing tree view are three buttons:
- Test Patch – (this will say Test Merge Proposal if a merge proposal). When you click this button, the project’s code will be downloaded and the patch/merge proposal will be automatically applied. When you have clicked this button, you can then use the embedded terminal at the bottom of the main view to go and run and test the patch. This makes applying patches incredible simple: you just click a button. If for some reason the patch or merge proposal has conflicts, a dialog box will appear providing details and possibly a button you can click which re-directs you to the bug in Launchpad to provide feedback that the patch did not apply.
- View Bug – (if applicable) if you want to view the bug that this patch/merge proposal fixes, click this button and it loads into your web browser.
- Leave Feedback – when you click this button you can go and provide input on the patch in Launchpad.
This is very much a first cut of the design, and is entirely open to discussion and improvement. The core idea is that we provide a TODO list of interesting patches/merge proposals to review based upon what the user is interested in, make testing them a single click, and make providing feedback a single click.
Writing this application would not be particularly complex from what I can tell. It is clearly a good candidate for a Quickly app, could use launchpad lib, and can use existing patch/diff/bzr tools. If one of you is interested in making Mergimus a reality, I recommend you just start writing some code, pop it in Launchpad and focus on a simple first cut and we can continue the discussion.