Planning for 10.10: Improving How We Review Patches

This is the first article in a series of posts where I will be outlining some of the goals for my team for the Ubuntu 10.10 cycle which I am in the process of planning for.

At the heart of Ubuntu development are gifts. People join our community and contribute in a diverse range of ways. This includes documentation, translations, advocacy and many other efforts. Every day we are afforded with many of these fantastic contributions, and if people take the time to contribute a gifts, we should work hard as a community to do the right thing and review and utilize it in Ubuntu if it meets our quality needs.

Fortunately, we have a rather incredible problem to solve: we have many gifts in the form of patches and not enough hands to open them, review them and apply them. This is something I am keen for us to make progress on in 10.10, and I have assigned Daniel Holbach from my team to work on this.

I am a firm believer that the first step in solving a problem is to optimize your visibility on the problem to understand it better, and with this in mind in the Lucid cycle Jorge and the Launchpad team performed some excellent work in putting together a patch view which provides a better and more accessible means of viewing all unreviewed patches for a given project. Beforehand these patches were scattered about Launchpad attached to bugs: now they are in a single view, providing an awesome TODO list for those who are keen to review patches and apply them. It looks like this:

In the 10.10 cycle I have asked Daniel to build a plan for how we can raise awareness of the importance of reviewing patches and how many of our tools and resources can help. We already have a lot of documentation and resources but I believe we need to optimize them for more people contributing and then go and encourage people to join the effort.

This is very much a community project that I have asked Daniel to drive: I think this is good and important work and we would love to hear your ideas about what can be done to improve how we (a) review these gifts (b) encourage more people to get involved and (c) ensure that patches can flow upstream easily. Thoughts?

  • http://www.anjuta.org Johannes

    Hi!

    I think it is utterly important to upstream most (maybe even) alle patches. Maybe even do that automatically. I would rather reject an ubuntu-specific patch than to loose a useful upstream patch on the way.

    So at least, the patch view should have a “push upstream” button that just reports the bug in the upstream bug-tracker (at least for the bigger projects, say GNOME, KDE, freedesktop, etc.). For the module maintainer it should be obvious if this is an upstream bug and he will just have to hit this button to inform the upstream maintainer. Discussion can continue in the upstream tracker than.

    Regards, Johannes

  • jono

    I agree. Something we have in the bug tracker in Launchpad is the ability to link a bug reported in Ubuntu with a bug that exists upstream or in another distribution. This provides a means for status to flow between bug reports.

    I think we need this for patches too: it would be great if patches that are provided for an Ubuntu package could be triggered and automatically flow upstream (possibly if they have their bug reports) linked. This is something I think we should definitely investigate.

  • Marc Randolph

    Howdy jono,

    My suggestions:

    1. Diff’s should work better: have the option to ignore whitespace.

    2. There should be a way to cause a merge from within launchpad (i.e., don’t have to “bzr merge” from a command line)

    Regards,

    Marc

  • http://www.justanothertriager.wordpress.com Nigel Babu

    The Ubuntu Reviewers team has been working on this. Any new patch attached to a bug report and reviewers team will be subscribed. Right now, we are using tags to track the status of patches. The workflow is still a work in progress as more people give out their opinion on it

  • http://knocte.blogspot.com/ Andrés G. Aragoneses

    For Gnome, maybe you could help/contribute and after, rely on, the results of the Gnome Census project [1]. I think you could bring some collaboration with them in regards to this issue, as I posted here [2].

    [1] http://blogs.gnome.org/bolsh/2010/03/17/the-gnome-census-project/ [2] http://blogs.gnome.org/bolsh/2010/03/24/interesting-gnome-census-problems/#comment-2591

  • http://www.jonobacon.org/2010/03/26/planning-for-10-10-growing-our-translations-community/ Planning For 10.10: Growing Our Translations Community | jonobacon@home

    [...] as with my previous 10.10 planning article, what feedback do you folks have that David can focus in on? [...]

  • http://anirudhsanjeev.org Anirudh

    I built a little tool to help people review patches:

    http://patchbin.com

    The code for the site is available as well http://github.com/ninjagod/patchbin

    Maybe this can find some use in the review process.

  • http://www.jonobacon.org/2010/03/30/mergimus-making-patch-and-branch-review-easier-in-ubuntu/ Mergimus: Making Patch And Branch Review Easier In Ubuntu | jonobacon@home

    [...] I blogged about how we are keen to improve patche 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 [...]

  • http://linux.uk.com/2010/03/31/jono-bacon-mergimus-making-patch-and-branch-review-easier-in-ubuntu/ Jono Bacon: Mergimus: Making Patch And Branch Review Easier In Ubuntu | Linux . uk . com

    [...] 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 [...]