4 ms·

Classic ML sucks, and gitlab is opensource that can be selfhosted. The world evolved and offers now better environments than 20 years ago. No reason to stay beh

Classic ML sucks, and gitlab is opensource that can be selfhosted. The world evolved and offers now better environments than 20 years ago. No reason to stay behind.

xte 8y ago
Well for me "evolving" from a standard thing to a monster web app that require far more resources and offer far less flexibility have a name: involution... Of course I know that many are limited to webmails or obsolete, limiting and limited MUAs from the '90s but that's again involution. If you have notmuch/emacs or (neo)vim *{mutt,pine} you have a far more advanced computing environment that no web up can even try to mach. "stay behind" today's often means stay in a modern and colorful stone age instead of powerful technology.
u801e 8y ago
> Classic ML sucks Could you elaborate on why that is? The git and linux kernel projects have been using this workflow for decades and it works very well for them. > The world evolved and offers now better environments than 20 years ago. I think that's largely subjective. I have experience reviewing code via email and via a Github Enterprise instance. The Github based review requires far more scrolling and makes it difficult to find comments that were made and how they were resolved. Plus, it makes the implicit assumption that a comment was resolved if the line commented on was changed in any way regardless of whether or not the change is related to the comment made. When that happens, it collapses the comment thread and requires that I expand them to find out what I commented on and determine whether it was addressed by going to another tab to read through the entire diff, find the approximate location of the line I commented on and see if it was changed as I expected. With the email based workflow, my email client has a built in index of all the comments made on a patch set threaded by commit that I can click on and I can quickly find the comments I made and any responses to them (and whether or not I've already read them). I can easily get different versions of the patch set and run a diff between them to see what changed (either on the entire diff or on each individual commit). > The world evolved and offers now better environments than 20 years ago. No reason to stay behind. I believe that if something should be considered an improvement, then it should have all the capabilities of the previous version and introduce new features that were not possible to accomplish in the previous version. It shouldn't make things that were easy to do in the previous version more difficult or impossible to do.
- 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.

Classic ML sucks, and gitlab is opensource that can be selfhosted. The world evolved and offers now better environments than 20 years ago. No reason to stay behind.

xte 8y ago

Well for me "evolving" from a standard thing to a monster web app that require far more resources and offer far less flexibility have a name: involution... Of course I know that many are limited to webmails or obsolete, limiting and limited MUAs from the '90s but that's again involution. If you have notmuch/emacs or (neo)vim *{mutt,pine} you have a far more advanced computing environment that no web up can even try to mach. "stay behind" today's often means stay in a modern and colorful stone age instead of powerful technology.

u801e 8y ago

> Classic ML sucks Could you elaborate on why that is? The git and linux kernel projects have been using this workflow for decades and it works very well for them. > The world evolved and offers now better environments than 20 years ago. I think that's largely subjective. I have experience reviewing code via email and via a Github Enterprise instance. The Github based review requires far more scrolling and makes it difficult to find comments that were made and how they were resolved. Plus, it makes the implicit assumption that a comment was resolved if the line commented on was changed in any way regardless of whether or not the change is related to the comment made. When that happens, it collapses the comment thread and requires that I expand them to find out what I commented on and determine whether it was addressed by going to another tab to read through the entire diff, find the approximate location of the line I commented on and see if it was changed as I expected. With the email based workflow, my email client has a built in index of all the comments made on a patch set threaded by commit that I can click on and I can quickly find the comments I made and any responses to them (and whether or not I've already read them). I can easily get different versions of the patch set and run a diff between them to see what changed (either on the entire diff or on each individual commit). > The world evolved and offers now better environments than 20 years ago. No reason to stay behind. I believe that if something should be considered an improvement, then it should have all the capabilities of the previous version and introduce new features that were not possible to accomplish in the previous version. It shouldn't make things that were easy to do in the previous version more difficult or impossible to do.

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.