Reviews

New review flow!

Ever since moving off github, we have been accepting contributions either thru git send-email or github PRs, or even (in trivial cases) just as patches in a pastebin over IRC. All of these have serious downsides.

We have played with the idea of using git-pr for accepting contributions. It's pretty good, but it has serious permissions bugs we encountered with very basic usage. Also it requires a completely separate SSH server instead of using openssh, which means it doesn't work with our current hosting provider. In addition, it uses ssh rather than real git remotes, which has pros and cons.

The real valuable insight of git-pr is the fact that review comments can exist as comments in commits that apply on top of the initial contribution. This allows a review flow to be built on top of existing primitives with minimal moving parts.

We have been thinking about what a solution looks like that actually does use git remotes. There's a simple implementation of this that sends pushes directly to email, but we would want something a little more structured.

What problems are we solving?

Contributors should be able to submit with lowest possible headache:

$ git remote add review [email protected]:fennel # initial setup
$ git push -u review mybranch
# wait for maintainer review
$ git pull
# look at maintainer comments in commits (or use a web ui?)
# edit to address comments
$ git commit -a -m whatever
$ git push review mybranch

• maintainers should be able to
  • see contributions
  • review them, comment on them
  • accept them
    • merge with history or squash?
    • we actually already have to make this decision normally
  • decline them

Design

• shadow repo for reviews
• git hook
  • permissions checks (how?)
    • new branch? anyone can create
    • existing branch? owner or admin can push
  • notifications
    • IRC
    • RSS?
    • email?
  • branch deletion
    • move to archive repo?
• cron job
  • pulls from sourcehut to main
  • checks for merged branches to archive
• how to manually archive a branch?

What data do we have to store?

• creator of a branch
• status of the branch, maybe?
  • with a separate archive repo, we might not need status
  • move branches to archive repo once they're done
    • visibility doesn't seem as good
• store this in the git branch description?
  • if we can prevent it from being edited
  • otherwise, sqlite? flat files?

Identify users by their SSH key.

• Can we collapse multiple keys into a single user? or alias keys together?

• Meta-repo that stores key alias mappings?

• Preventing abuse

  • Size limit for commits and branches
  • Rate limiting
  • Key bans; IP bans?

Well?

Is this flow better enough from git-pr to justify making our own thing?

Maybe, if it's fun!