3 ms·

Not answering your points against GitHub, they're valid and I mostly agree on them. About your "for email all I need to do is": this looks simple and neat (and

Not answering your points against GitHub, they're valid and I mostly agree on them. About your "for email all I need to do is": this looks simple and neat (and even then, does it really?) when you already know how it works. But it took me several hours of googling around to understand what I was supposed to do (I need to configure git to send emails?), how to do it (get the right sendEmail config is non-trivial), learn about multiple git commands I never heard about and never used outside of this process (format-patch, am, send-email) and their various flags, iterate to get the correct flags while quadruple-checking everything to make sure I don't send garbage on the mailing list and bother everybody, get told I didn't respect a half-dozen conventions (no HTML in emails, 80-char lines, format of the commits, the email subject and the cover letter, people CC'd...), iterate several times to finally have a patch that respects enough conventions that people are OK looking at it. I had to change my email client because it's basically impossible to respect these conventions or follow discussions without a specialised client à la Mutt, which meant more hours downloading, configuring and learning a new tool. And then I get feedback fragmented over several emails instead of a single interface, spend a ridiculous amount of time answering to make sure you respect conventions, never have a clear resolution of a feedback. I submitted a copy change patch about a year after my first patch, and it still took me hours to get it right. The process you're explaining makes sense and seems simple when you are already familiar with it. When you're not, it's just hours of head scratching and trying to make sense of it. Which would be fine if that was a process everybody used, we'd just learn it and practice, but nowaday very very few projects use it: I've never had to go through all these hoops ever again. Which makes it a crazy high barrier to entry and feel old and obsolete. And maybe the high barrier to entry is considered a good thing by git/linux people, it's their right, but let's not pretend it doesn't exist

u801e 6y ago
> About your "for email all I need to do is": this looks simple and neat (and even then, does it really?) when you already know how it works At one time, I didn't know how it worked, but I read through the documentation (man pages for git, git format-patch, git send-email, and git am). To be fair, when you create a new repo or fork a repo, Github will display the commands necessary to set your repository's origin or cloning the repository. It probably also tells you the commands necessary to push commits to the remote or pull from it. There is documentation out there that gives you a general idea about how to submit patches, coding conventions, etc in [1]. It certainly would be nice if they added a short tl; dr section on how to configure git for using the format-patch and send-email commands (similar to what I did in my previous post). > get told I didn't respect a half-dozen conventions (no HTML in emails, 80-char lines, format of the commits, the email subject and the cover letter, people CC'd...), This is all documented in the SubmittingPatches file in the git repo itself in the Documentation directory. The maintainer and major contributors have to go through a lot of submitted patches and they, for better or worse, will apply a filter on what they accept. But reading through a text file to learn the conventions and requirements shouldn't be considered a barrier to entry. > while quadruple-checking everything to make sure I don't send garbage on the mailing list and bother everybody, The best way to do that is to test it against your own email account. > I had to change my email client because it's basically impossible to respect these conventions or follow discussions without a specialised client à la Mutt, A GUI client like Thunderbird would have worked for viewing threaded conversations and participating in them. In fact, there are a number of GUI email clients that support threaded view [2] (but would need to be configured to only send plaintext email). Submitting patches, on the other hand is best accomplished by using the format-patch and send-email commands since they ensure correct formatting. But the project could certainly do a better job documenting the actual set of commands and flags used for generating the patches and then submitting them (along with re-rolls). But the lack of concise documentation for the settings and workflow isn't something that makes the email workflow inferior or obsolete. > then I get feedback fragmented over several emails instead of a single interface The feedback is on a per commit basis. A patchset consisting of multiple commits can make for a large diff and make it more difficult to review (and require far more scrolling to view the diff and the comments in the Github conversation view). An email client with an index view of the commits along with their associated comment threads makes it easy to see which comments have been read or not, what you've replied to, etc. > Which makes it a crazy high barrier to entry and feel old and obsolete. And maybe the high barrier to entry is considered a good thing by git/linux people, it's their right, but let's not pretend it doesn't exist I guess the real argument comes down to whether reading documentation and reading through the mailing list before submitting a patch should be considered a high barrier for entry. Regardless of whether a project is managed via email, Github/Gitlab, or some other tool like Gerrit or Phabricator, there are always some conventions to follow in terms of code organization, style, commit message conventions, etc. At some point, one will have to learn by observing how things work from previous submissions and/or read through the documentation. There may be people who are willing to lead others through the process and show them what to do, but, that's not always the case. I guess you could think of it as joining in a game that people are playing (soccer, basketball, poker, etc), but not knowing the rules. You could either read up on the rules beforehand and watch how they play before joining in or just start participating and learn as you play. But if you keep making mistakes and not respond to feedback, then others will be less inclined to work with you. [1] https://github.com/git/git/tree/master/Documentation https://github.com/git/git/tree/master/Documentation [2] https://en.wikipedia.org/wiki/Comparison_of_email_clients#General_features https://en.wikipedia.org/wiki/Comparison_of_email_clients#Ge...

u801e 6y ago

> About your "for email all I need to do is": this looks simple and neat (and even then, does it really?) when you already know how it works At one time, I didn't know how it worked, but I read through the documentation (man pages for git, git format-patch, git send-email, and git am). To be fair, when you create a new repo or fork a repo, Github will display the commands necessary to set your repository's origin or cloning the repository. It probably also tells you the commands necessary to push commits to the remote or pull from it. There is documentation out there that gives you a general idea about how to submit patches, coding conventions, etc in [1]. It certainly would be nice if they added a short tl; dr section on how to configure git for using the format-patch and send-email commands (similar to what I did in my previous post). > get told I didn't respect a half-dozen conventions (no HTML in emails, 80-char lines, format of the commits, the email subject and the cover letter, people CC'd...), This is all documented in the SubmittingPatches file in the git repo itself in the Documentation directory. The maintainer and major contributors have to go through a lot of submitted patches and they, for better or worse, will apply a filter on what they accept. But reading through a text file to learn the conventions and requirements shouldn't be considered a barrier to entry. > while quadruple-checking everything to make sure I don't send garbage on the mailing list and bother everybody, The best way to do that is to test it against your own email account. > I had to change my email client because it's basically impossible to respect these conventions or follow discussions without a specialised client à la Mutt, A GUI client like Thunderbird would have worked for viewing threaded conversations and participating in them. In fact, there are a number of GUI email clients that support threaded view [2] (but would need to be configured to only send plaintext email). Submitting patches, on the other hand is best accomplished by using the format-patch and send-email commands since they ensure correct formatting. But the project could certainly do a better job documenting the actual set of commands and flags used for generating the patches and then submitting them (along with re-rolls). But the lack of concise documentation for the settings and workflow isn't something that makes the email workflow inferior or obsolete. > then I get feedback fragmented over several emails instead of a single interface The feedback is on a per commit basis. A patchset consisting of multiple commits can make for a large diff and make it more difficult to review (and require far more scrolling to view the diff and the comments in the Github conversation view). An email client with an index view of the commits along with their associated comment threads makes it easy to see which comments have been read or not, what you've replied to, etc. > Which makes it a crazy high barrier to entry and feel old and obsolete. And maybe the high barrier to entry is considered a good thing by git/linux people, it's their right, but let's not pretend it doesn't exist I guess the real argument comes down to whether reading documentation and reading through the mailing list before submitting a patch should be considered a high barrier for entry. Regardless of whether a project is managed via email, Github/Gitlab, or some other tool like Gerrit or Phabricator, there are always some conventions to follow in terms of code organization, style, commit message conventions, etc. At some point, one will have to learn by observing how things work from previous submissions and/or read through the documentation. There may be people who are willing to lead others through the process and show them what to do, but, that's not always the case. I guess you could think of it as joining in a game that people are playing (soccer, basketball, poker, etc), but not knowing the rules. You could either read up on the rules beforehand and watch how they play before joining in or just start participating and learn as you play. But if you keep making mistakes and not respond to feedback, then others will be less inclined to work with you. [1] https://github.com/git/git/tree/master/Documentation https://github.com/git/git/tree/master/Documentation [2] https://en.wikipedia.org/wiki/Comparison_of_email_clients#General_features https://en.wikipedia.org/wiki/Comparison_of_email_clients#Ge...