[IMP] runbot_merge: readme updates

runbot_merge/README.rst

@@ -7,9 +7,8 @@ Setup
 * Setup a project with relevant repositories and branches the bot
   should manage (e.g. odoo/odoo and 10.0).
 * Set up reviewers (github_login + boolean flag on partners).
-* Sync PRs.
+* Add "Issue comments", "Pull request reviews", "Pull requests" and
-* Add "Issue comments","Pull requests" and "Statuses" webhooks to
+  "Statuses" webhooks to managed repositories.
-  managed repositories.
 * If applicable, add "Statuses" webhook to the *source* repositories.
 
   Github does not seem to send statuses cross-repository when commits
@@ -71,15 +70,15 @@ retry
 r(review)+
   approves a PR, can be used by a reviewer or delegate reviewer
 
-r(eview)-
+  submitting an "approve" review implicitly r+'s the PR
-  removes approval from a PR, currently only active for PRs in error
-  mode: unclear what should happen if a PR got unapproved while in
-  staging (cancel staging?), can be used by a reviewer or the PR
-  author
 
-squash+/squash-
+r(eview)-
-  marks the PR as squash or merge, can override squash inference or a
+  removes approval from a PR, allows un-reviewing a PR in error (staging
-  previous squash command, can only be used by reviewers
+  failed) so it can be updated and re-submitted
+
+.. squash+/squash-
+..   marks the PR as squash or merge, can override squash inference or a
+..   previous squash command, can only be used by reviewers
 
 delegate+/delegate=<users>
   adds either PR author or the specified (github) users as authorised
@@ -91,32 +90,11 @@ p(riority)=2|1|0
   lower-priority PRs are selected first and batched together, can be
   used by reviewers
 
-  currently only used for staging, but p=0 could cancel an active
+rebase-
-  staging to force staging the specific PR and ignore CI on the PR
+  the default merge mode is to rebase and merge the PR into the
-  itself? AKA pr=0 would cancel a pending staging and ignore
+  target, however for some situations this is not suitable and
-  (non-error) state? Q: what of co-dependent PRs, staging currently
+  a regular merge is necessary; this command toggles rebasing
-  looks for co-dependent PRs where all are ready, could be something
+  mode off (and thus back to a regular merge)
-  along the lines of::
-
-      (any(priority = 0) and every(state != error)) or every(state = ready)
-
-TODO
-----
-
-* PR edition (retarget, title/message)
-* Ability to disable/ignore branches in runbot (tmp branches where
-  staging is being built)
-* What happens when cancelling staging during bisection
-
-TODO?
------
-
-* Prioritize urgent PRs over existing batches?
-* Make autosquash dynamic? Currently PR marked as squash if only 1
-  commit on creation, this is not changed if more commits are added.
-* Use actual GH reviews? Currently only PR comments count.
-* Rebase? Not sure what use that would have & would need to be done by
-  hand
 
 Structure
 ---------
@@ -145,7 +123,7 @@ Notes
   isolating e.g. if there's a single high-priority PR, low-priority
   PRs are ignored completely and only that will be staged on its own
 * Reviewers are set up on partners so we can e.g. have author-tracking
-  & deletate reviewers without needing to create proper users for
+  & delegate reviewers without needing to create proper users for
   every contributor.
 * MB collates statuses on commits independently from other objects, so
   a commit getting CI'd in odoo-dev/odoo then made into a PR on
@@ -156,13 +134,11 @@ Notes
   to be rollbacked e.g. a staging succeeds in a 2-repo scenario,
   A.{target} is ff-d to A.{staging}, then B.{target}'s ff to
   B.{staging} fails, we have to rollback A.{target}.
-* Batches & stagings are non-permanent, they are deleted after success
-  or failure.
 * Co-dependence is currently inferred through *labels*, which is a
-  pair of ``{login}:{branchname}``
+  pair of ``{repo}:{branchname}`` e.g. odoo-dev:11.0-pr-flanker-jke.
-  e.g. odoo-dev:11.0-pr-flanker-jke. If this label is present in a PR
+  If this label is present in a PR to A and a PR to B, these two
-  to A and a PR to B, these two PRs will be collected into a single
+  PRs will be collected into a single batch to ensure they always
-  batch to ensure they always get batched (and failed) together.
+  get batched (and failed) together.
 
 Previous Work
 -------------
@@ -184,7 +160,6 @@ Why not bors-ng
 * can't do co-dependent repositories/multi-repo staging
 * cancels/forgets r+'d branches on FF failure (emergency pushes)
   instead of re-staging
-* unclear whether prioritisation supported
 
 homu
 ~~~~