Bzg/woof: online monitor for mailing list based patch workflow

A patch/diff workflow operates at the level of individual diffs, rather than a branch identified by base and head refs like with pull requests.

Email is one (very clunky) way of implementing such a workflow, there's other tools like Gerrit, Reviewable or Phabricator that are more friendly.

Using email to review patches is completely absurd. The following is a contentious statement but there's no avoiding it: it's done nowadays by people who started doing it in the 80s and 90s and are being stubborn. Here are some reasons email should not be used for review, if any are really needed:

- A "patch" must have a defined parent. Otherwise it is not defined what state of the overall codebase is being reviewed.

- Proposed changes evolve through complex lifecycles of comments/discussions and updates. Some comments are global and some should be attached to specific lines of code as it exists in a specific revision. This complexity is (obviously!) better modeled by a dedicated UI than by shoe-horning it into plain text email.

- It makes sense to attach the dynamic status of test runs to these updates. This can be done in a web UI but cannot be done in an email.

- Commenting on individual lines of code is desirable and (obviously!) better done by attaching a discussion thread to a defined (revision + code coordinates) location in a diff view than by replying inline in an email. The reasons (if they really need stating) include (1) that breaking a diff manually in an email and replying inline makes it hard to assemble the diff in your head, (2) it is not possible to have clearly readable discussion threads involving multiple people with each thread attached to a certain line in the diff, (3) it's certainly not possible to keep that discussion coherent when the underlying patch is evolving.

- Not everyone uses, or wishes to use, plain text emails.

- Not everyone uses or wishes to use a text-based email client that runs on their local machine. Nor do they have, or wish to have, their emails present on their local machine (they want their emails stored online and accessed via a web interface).

(And yes, I am someone who has used mutt, and gnus, and dovecot, and offlineimap.)

- The history/evolution of a codebase can be represented by a graph structure. It makes sense for review discussion to be associated with this graph structure. This is what Bitbucket/Github/Gitlab provide. Email does not provide this. There's a risk with email that it won't even be publicly searchable, but supposing it exists, a web-hosted archive of emails is not an effective way to comprehend the history of a codebase.

As a cultural observation, the people who are still insisting on email are often the sorts of people who insist that email should be plain text and actually look down upon technical people who like web-hosted email clients and HTML emails, and they are sometimes the sorts of people who deride Github as being nonserious -- full of "kids" who carelessly propose ill-thought out change sets and expect them to be incorporated into public projects. Neither of those positions are reasonable or speak highly of the holder.