On 19/12/2013 07:08, Quoth Peter A. Bigot:
As I read that thread, much of what he objected to was github's web commit interface making it difficult/impossible for contributions to conform to the kernel patch standards, and that github pull requests did not meet his work flow requirements.
The first part is eliminated if the developer pushes to a github fork using standard git commands; then the pull request is simply a notification of a proposed submission, which must still conform to the upstream project's expectations. The second is only relevant if Boost maintainers adopt Torvald's email-oriented workflow.
My experience with using github forks to interact with upstream projects/downstream contributors has been that it is convenient to both submitter and reviewer, since a cursory inspection can be done on the web without integrating a mailer with one's development environment or having to pull the changes into a local workspace. The ability to provide comments in context with specific commits is also valuable.
+1 Most of his remarks are how GitHub isn't suited to the Linux-kernel-specific workflow, and aren't really relevant to any other projects. And about the word wrapping, he's just *wrong*. :)