Re: to PR or not to PR, is /that/ the question?

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi Giovanni,

Thank you for your detailed message.  Sorry, I have not read all the
details because I have been lost.  What do you want to explain?

Well, let me explain my understanding using my own words. :-)

When one reduces to the core of the workflows, the main difference
between “email workflow” and “PR workflow” is the way the submitter
sends the code to the reviewer.

 1. email workflow: the diff are sent by email.
 2. PR workflow: the diff are sent by the VCS itself.

Then, we can put a lot of glue around these workflows.  It is possible
to work in a centralized fashion or in a distributed fashion.  It is
possible to use a proprietary service for delegating some parts using a
button via a web-interface.  It is possible to have a service based on
free software that automatize some parts of the workflow.  Etc

By glue, it reads a range from mailing list to Github, or from Gitlab to
Sourcehut, or from personal custom scripts to tools as B4, public-inbox,
Gerrit, patchwork, etc.

Obviously, the PR workflow also depends on the features of the
underlining VCS when the email workflow not.  Bitbucket provided a PR
workflow for Mercurial.  And a PR workflow would be hard to implement
using Subversion or worse using CVS.

Note that the email workflow #1 might be centralized.  That’s what we
are doing when using one mailing list; there is only one unique location
for exchanging all pieces of code.  Or it might be decentralized, that’s
how the contributors send their contribution to some linux kernel
maintainers.

Note that the PR workflow #2 might be decentralized.  That’s more or
less how Linus Torvald’s “lieutenants” are doing for asking a merge in
the Linus’s mainline linux kernel.  Or it might centralized and
web-forges provide many examples. :-)

The requirement for #1 is just being able to send emails.  The
requirement for #2 is to have a public Git repository.

Both workflows have pros and cons.  And then these pros and cons also
depend on how the workflow is implemented.  And none is not much better
than the other.

The slight difference between the two is the state of the contribution
from the reviewer perspective:

    . About the email workflow #1, the patches might not apply for many
reasons but because they are sent by email, the notification “hey give a
look to thing” and the “diff for thing“ are synchronized.

    . About the PR workflow #2, the patches belong to a Git repository
so they are already applied.  However, between the notification “hey
give a look to thing” and the moment when the reviewer pulls the thing,
the Git repository might disappear, be replaced, history rewritten, etc.

Well, that’s my understanding of the difference between #1 and #2.  A
bit simplified but it captures my understanding of the main, I
guess. :-)

Cheers,
simon