3 ms·

Not the GP, but I contribute to the Git project. I think your some of your critique of GitHub Enterprise is correct (although don't you need to also "resolve di

by avar 8y ago

Not the GP, but I contribute to the Git project. I think your some of your critique of GitHub Enterprise is correct (although don't you need to also "resolve discussion" if the lines change, or is that just GitLab?), just commenting on the "why not ML" aspect of this. > With the email based workflow, my email client has a built in index of all the comments made[...] The reason for why E-Mail based workflows like those used by Linux and Git didn't win over "just host on Git(Hub|Lab)" is because this requires a lot of setup & technical expertise from your contributors that just using a web UI gives you out of the box. Right off the bat you need to have been subscribed to the list for a significant amount of time to do what you're describing, or if you're lucky (e.g. in the case of the Git project) use some E-Mail archive[1]. You're already looking at maybe a week of setup time for someone who's never used E-Mail in this way (which applies for most devs these days) just to get to the point you'd get in 10 seconds with a search box on GitHub or GitLab. Does it pay off in a lot of ways? Sure, but at the cost of losing a lot of potential contributors. It's not a big deal for projects like linux.git or git.git whose contributors are by definition at the tail end of the competency curve when it comes being comfortable with setting up this sort of thing, but good luck running e.g. some popular WordPress plugin this way. 1. https://public-inbox.org/git/ https://public-inbox.org/git/

u801e 8y ago
> although don't you need to also "resolve discussion" if the lines change, or is that just GitLab? I believe Github recently deployed a feature to do just that, but that hasn't made it over to the enterprise version. In either case, it's something that's been a source of problems for quite a few years. > Right off the bat you need to have been subscribed to the list for a significant amount of time to do what you're describing That's one inherent limitation with email lists. Fortunately, both public-inbox and gmane provide a NNTP gateway to allow for access to list archives with an interface that's, for all practical purposes, identical to email. As an aside, I've always wondered why open source projects like git and linux never adopted NNTP (not necessarily on usenet) as a primary form of communication (and and email CC contributers of code that you're changing) instead of using an email list. > this requires a lot of setup & technical expertise from your contributors [...] You're already looking at maybe a week of setup time I simply don't see how it requires significant expertise or a week to set up. Using a client like Thunderbird for reading the list (or NNTP gateway) doesn't take that much to set up (other than entering the server information and credentials to send replies). Setting up one's git configuration for using git-send-email (to send patches) is only a one time thing as well and isn't any more complex. Years ago, ISPs commonly provided help pages that gave the server information to set up your client to access one's email account hosted on the ISP and how to access the NNTP server to get on usenet. You didn't need significant technical expertise to follow the instructions on those pages and many non-technical people successfully configured their clients to receive/send their email and participate on usenet newsgroups.
- avar 8y ago
  > I simply don't see how it requires significant expertise or a week to set up[...] I don't just mean the setup required to send a one-off patch. Obviously setting up some random E-Mail client with IMAP is easy. But the sort of setup required to get anything like feature parity with common operations in GitHub's or GitLab's interface. E.g. when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. And nowadays the network effects of that setup don't make sense for most contributors, because so few projects still use E-Mail like this. There's a large long tail of contributors to these projects, e.g. the median for patches in git.git per contributor is 2.
  - u801e 8y ago
    > when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. That's a good point. Like git-am is the inverse of git-format-patch. Unfortunately, no program has been written as the corresponding inverse of git-send-email. If a program like that existed, then one could get feature parity. At least with Thunderbird, one can highlight the messages one wants to save and save them to multiple files in a folder. > Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. Based on what I've read, people typically rebase their patch series and push up a new set of emails as a reply to the original patch series. In Github/Gitlab, people typically make an incremental commit and push it up. But, if one wants to maintain a clean commit history for a given feature development branch before it's merged, one will have to rebase and apply those incremental commits to their corresponding base commit. That's trivial if the feature is implemented in a single commit, but a bit more complex if it's multiple commits. The former case has been addressed by Github with their squash before merge feature I believe. The latter case requires manual rebasing (which arguably is more more than just doing it locally before pushing up the next version of the patch set).
xte 8y ago
> The reason for why E-Mail based workflows like those used by Linux and Git didn't win over "just host on Git(Hub|Lab)" is because this requires a lot of setup [...] That's a reasoned recurring argument and my usual answer is: quality vs quantity. More in detail we are not talking about a hello world software for first years of high schools students but large and complex software; if casual contributors do not have a proper email setup or the knowledge to make it it means they probably do not have enough IT knowledge in general to be valuable contributors. Emails are the base of FOSS communication infrastructure together with nntp news, without them there is substantially no free software nor free "ecosystems" so... However there is a point in criticize actual "sorry state" of email development. I know "bigs of IT" do non like mails because they are an open standard that guarantee no lock-in but we as free software users/devs should help newcomers to gain knowledge and tell actual students "go get mbsync/notmuch/emacs/custom scripts for refile/delete afew/IMAPFilter for autorefile, ..." does not help, offer per-coocked solutions does. Something is happening from fish to precooked zsh configs to {doom,prelude,spacemacs,...} emacs config etc but it's still not enough.

by avar 8y ago

u801e 8y ago

> although don't you need to also "resolve discussion" if the lines change, or is that just GitLab? I believe Github recently deployed a feature to do just that, but that hasn't made it over to the enterprise version. In either case, it's something that's been a source of problems for quite a few years. > Right off the bat you need to have been subscribed to the list for a significant amount of time to do what you're describing That's one inherent limitation with email lists. Fortunately, both public-inbox and gmane provide a NNTP gateway to allow for access to list archives with an interface that's, for all practical purposes, identical to email. As an aside, I've always wondered why open source projects like git and linux never adopted NNTP (not necessarily on usenet) as a primary form of communication (and and email CC contributers of code that you're changing) instead of using an email list. > this requires a lot of setup & technical expertise from your contributors [...] You're already looking at maybe a week of setup time I simply don't see how it requires significant expertise or a week to set up. Using a client like Thunderbird for reading the list (or NNTP gateway) doesn't take that much to set up (other than entering the server information and credentials to send replies). Setting up one's git configuration for using git-send-email (to send patches) is only a one time thing as well and isn't any more complex. Years ago, ISPs commonly provided help pages that gave the server information to set up your client to access one's email account hosted on the ISP and how to access the NNTP server to get on usenet. You didn't need significant technical expertise to follow the instructions on those pages and many non-technical people successfully configured their clients to receive/send their email and participate on usenet newsgroups.

avar 8y ago
> I simply don't see how it requires significant expertise or a week to set up[...] I don't just mean the setup required to send a one-off patch. Obviously setting up some random E-Mail client with IMAP is easy. But the sort of setup required to get anything like feature parity with common operations in GitHub's or GitLab's interface. E.g. when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. And nowadays the network effects of that setup don't make sense for most contributors, because so few projects still use E-Mail like this. There's a large long tail of contributors to these projects, e.g. the median for patches in git.git per contributor is 2.
- u801e 8y ago
  > when you open a Pull/Merge request on those sites. It's easy to apply & download the patch series locally to test it. For E-Mail client integration you need something that'll "git am" a range of messages. That's a good point. Like git-am is the inverse of git-format-patch. Unfortunately, no program has been written as the corresponding inverse of git-send-email. If a program like that existed, then one could get feature parity. At least with Thunderbird, one can highlight the messages one wants to save and save them to multiple files in a folder. > Likewise with "git push" to your topic branch updating the PR/MR. Sure you can do this all manually with git-format-patch and git-send-email, but having something that works smoothly takes a lot of work. Based on what I've read, people typically rebase their patch series and push up a new set of emails as a reply to the original patch series. In Github/Gitlab, people typically make an incremental commit and push it up. But, if one wants to maintain a clean commit history for a given feature development branch before it's merged, one will have to rebase and apply those incremental commits to their corresponding base commit. That's trivial if the feature is implemented in a single commit, but a bit more complex if it's multiple commits. The former case has been addressed by Github with their squash before merge feature I believe. The latter case requires manual rebasing (which arguably is more more than just doing it locally before pushing up the next version of the patch set).

xte 8y ago

> The reason for why E-Mail based workflows like those used by Linux and Git didn't win over "just host on Git(Hub|Lab)" is because this requires a lot of setup [...] That's a reasoned recurring argument and my usual answer is: quality vs quantity. More in detail we are not talking about a hello world software for first years of high schools students but large and complex software; if casual contributors do not have a proper email setup or the knowledge to make it it means they probably do not have enough IT knowledge in general to be valuable contributors. Emails are the base of FOSS communication infrastructure together with nntp news, without them there is substantially no free software nor free "ecosystems" so... However there is a point in criticize actual "sorry state" of email development. I know "bigs of IT" do non like mails because they are an open standard that guarantee no lock-in but we as free software users/devs should help newcomers to gain knowledge and tell actual students "go get mbsync/notmuch/emacs/custom scripts for refile/delete afew/IMAPFilter for autorefile, ..." does not help, offer per-coocked solutions does. Something is happening from fish to precooked zsh configs to {doom,prelude,spacemacs,...} emacs config etc but it's still not enough.