GOP-PROP 13: patch management tools

[Graham Percival]

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.

http://lilypond.org/~graham/gop/gop_13.html


** 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.
    * 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: automatically switch any Patch-review to
      Patch-needs_work if there are any non-LGTM 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. 


Cheers,
- Graham