Pull Requests vs Patches

Introduction

  • Prerequisits and context.
  • Explain workflows.
  • Discuss technical details.
  • Compare.
  • Conlude.

Terminology

Discussion list
mailing list.
Forge
collaboration web site.
Merge request
the same as pull request.

Important properties

Reliability

  • Work without network.
  • Work with partial availability.
  • Do not rely on trust for third-parties.

Attention/Concentration

Number of repetative actions

Privacy and Security

  • No tracking.
  • No spyware and ransomware.

Learning curve and setup complexity

Acquaintance

PR workflow

Contributing

  • Once
    • Setup mail account.
    • Setup gpg.
    • Setup ssh.
  • Once per Forge
    • Sign up/Generate password.
    • Setup ssh/gpg keys.
  • Once per Project
    • Fork the repo.
    • Clone it.
    • Setup upstream remote.
  • Discussing Proposal
    • Create issue.
    • Discuss it lineary.
  • Preparing and Submiting Changes
    • Pull from the upstream.
    • Create a local feature branch.
    • Commit changes.
    • Push to fork.
    • Open a browser, Create a PR and wait for reviews.
    • Check CI passes.
    • Link the discussion. centralized-github-4.png
  • Interacting with reviewer
    • Read the comments.
    • Find the place in the code.
    • Apply changes.
  • Cleanup
    • Remove local branch.
    • Remove remote branch.
    • Close issue.

Accepting contribution

  • Once per contributor
    • Add remote
  • Reviewing changes
    • Review in browser or
    • Pull remote.
    • Jump back and force between IDE and browser, "syncronize" line and post comments.

ML workflow

Contributing

  • Once
    • Setup mail account.
    • Setup gpg.
    • Setup mail client.
  • Once per project
    • Clone the repository.
  • Once per ML [optional]
    • Add it to the sync tool.
  • Discussing/Reviewing/Submiting
    • Create a thread.
    • Reply to the message in a subthread.
    • Attach a patch or a few.

Accepting contribution

  • Apply patch or a few.

Comparison

Communication and Review

  • Full-fledged dev tools vs Web-based text editor for review. (Intermediate forge-dependent semi-IDE, which can be changed anytime?)
  • Custom patch format vs Configurable commit deltas representation.
  • Complete [BROKEN LINK: notmuch-tree:thread:{tag:example}] vs Diverse issues/PRs/inline review comments.
  • Specialized threaded discussions vs Linear mixed list of comments.
  • Persistent durable discussion vs ephemeral commits and comments.
  • Possibility to interject and provide changes.
  • Easy to pick up and carry on a stale [BROKEN LINK: notmuch-tree:id:20210703165127.12316-1-brice@waegenei.re].
  • Private discussion inside [BROKEN LINK: notmuch:id:87lf7x5lb5.fsf@gnu.org].

CI/Testing

Offline work

  • Forum with all discussions and changes
  • Full-text search

Sample emails

[BROKEN LINK: notmuch-tree:thread:{tag:example}]
list of examples
[BROKEN LINK: notmuch-tree:id:20210613101538.10668-1-ludo@gnu.org]
proper threading for v2

Problems of ML and Possible Solutions

Flexibility

  • Posibility to screw up the subject.
  • Reply to wrong subthread and/or recipients.
  • Inline and inline/attachment patches.

CI for patches in the thread

Unfamiliarity

  • Well-defined contribution guidlines
  • [BROKEN LINK: No match for fuzzy expression: (feature-mail-settings]

Spam

Comprehensive list of issues

  • Part of the git
  • Part of the forge

Joining to ML later

Social-prove

  • Mirror on github?

Small Demo

[BROKEN LINK: notmuch-tree:id:87y2akhiz1.fsf@trop.in]

Conclusion

  • The problems exist, but they are not blockers.
  • ML provides integrated experience.
  • Privacy and attention friendly.
  • Reliability and federated nature.
  • Flexible and really comfy.

Links