13. GOP 13 - patch management tools

Appropriately enough for “unlucky” number 13, this proposal is not well-prepared. However, I’m bringing it forward in in the interest of transparency and possibly gathering momentum.

Proposal summary

There is a fair amount of confusion with the current setup. Let’s either:

1. Find a different patch management tool
2. Find a different patch and issue management tool
3. Write a few python scripts to make our lives better

I favor the last option.

Rationale

Nobody seems happy with the current state of affairs.

Different patch and issue managment tools

There are a few alternatives that have been mentioned. I spent about two minutes looking at each website while having my Sunday dinner (can of corn, cheddar cheese, and a handful of strawberries), and I’m not impressed. Of course, this is an absolutely RIDICULOUSLY insignificant amount of effort to spend on something this fundamental to our project. If anybody wants to seriously examine some or all of these, I’m happy to withdraw this proposal until we have some actual evidence.

• http://github.com: has an issue tracker, but it’s rather limited. Nice merging capabilities, though.
• http://code.google.com/p/gerrit/: appears to be a fork of Rietveld. Not certain about hosting. You can play with it here http://server.kainhofer.com:8088/
• Google code review with git: google code itself supports git now; Carl has an example project here: http://code.google.com/p/plant-sim/source/list
• http://trac.edgewall.org/: based on a wiki, requires a host.
• http://www.redmine.org/: written in ruby, require a host.
• http://codestriker.sourceforge.net/: not certain about git support.
• http://www.reviewboard.org/: offers hosting.

Integrated tool?

There is some desire to have an integrated tool to handle both issues and patches. At the present time, I am against any move away from our google code issue tracker.

• We don’t want to host any tracker ourselves; google has more bandwidth than God, and anecdotally the issue tracker is very stable. It becomes read-only for a few hours once every couple of months, but that’s no problem.
• We have a huge investiment in the current issue tracker; moving hundreds of bugs would be a pain. Trust me, I was the one who added the old bugs from cvs to the current tracker.
• Google code issue tracker has the slickest interface for bug handling that I’ve ever seen. I’m not saying there’s not some unknown system out there that rocks, but in all my years of experience with numberous open-source projects, google code is far better than anything else.

Python scripts

Instead of a different tool, I think we should automate tasks with python. Google code has a python api which is absolutely fantastic:

http://code.google.com/p/support/wiki/IssueTrackerAPIPython

With that api, we can automatic a lot, with very little programming time required:

• 30-120 minutes: modify git-cl to automatically add a Patch-new issue whenever there’s an upload. If the issue description contains "issue 1234" or "fix 1234", it adds the rietveld url to the appropriate issue instead. I’ve already forked the git-cl repo and started work on this on https://github.com/gperciva/git-cl
• 1-3 hours: write a script that checks that every Patch-new can apply to master, compiles correctly, and creates a regtest comparison so the local human can check it and make it Patch-review instead. If there’s a problem before the regtest comparison, the script automatically changes it to Patch-needs_work.
• 1-2 hours: script that creates the patch countdowns. Any patch for a Type-Critical or Type-Maintainability is included, then it brings the total up to 10 patches, and sends the email to -devel.
• 1-5 hours: some kind of automatic processing to downgrade Patch-review to Patch-needs_work for certain types of comments.
• 30-60 minutes: moves any Patch-needs_work to Patch-abandoned after 100 days of inactivity.
• Almost certainly more.

Implementation notes

Now that I’ve seen how nice the gdata API is, I’m sorely tempted to cancel GOP for the next couple of weeks so that I can write all the scripts myself. If somebody else wants to do it (with or without any mentoring from me), that’s fine.

This document was generated by Graham Percival on June 13, 2012 using texi2html 1.82.