Re: Development suggestions from an ENSIME developer

[Stefan Monnier]

> The number of manual actions one needs to do when processing a patch
> can be counted, and the counts can be compared.  The "normal" speed of
> each operation can also be measured.  So I see no issues of coming up
> with a more-or-less objective assessment of the proposed workflow vs
> the existing one.

I think in the best-case scenario, a merge-request system won't help
very much
1a- You look at the patch in your email
1b- You look at the patch in your the MRS
2a- You think it looks good
2b- You think it looks good
3a- You M-| it to "git am; git push"
3b- You accept the request

But in my experience, step "3a" all too often doesn't work out so
nicely, because the patch is not quite in the right format.  With some
luck it's been word-wrapped or worse.  In practice I find "3a" to be
surprisingly time-consuming.  The merge-request flow avoids
those pitfalls.

Also, the "1a" step can be fairly different from "1b" because the tool
knows it's a patch, it knows against which branch in which repository it
applies, etc... so "1a" can precompute specialized extra info, such as:
- the result of a tentative build (compilation warnings and regression
  tests, tho that depends on having such a system setup and having the
  resources to run it for every merge-request (and every update of it)).
- a diff w.r.t the previous version of that same merge request.
- info about the fact that the patch doesn't apply against "master"
  any more.
- hopefully/ideally the tool could have already checked copyright.list
  for you.
- ...

Depending on the actual tool you end up using and other considerations,
an MRS can also offer further advantages (don't know enough about
Kallithea nor Gitlab to know if they offer those features):
- "3b" can just mark the request as "reviewed by <foo>", so you can give
  "half-commit" rights to some users.
- it sometimes makes it easier for 3rd parties (or for the reviewer) to
  update the merge request directly (instead of adding comments).

Of course, there's also the effect on the side of the patch-submitters,
where the precise flow is often made easier for them because there's no
doubt about where to send the patch, in which format, etc...


        Stefan