9 ms·

> It frustrates me that these projects still use mailing lists and have no sane UI to track issues, submit PRs like Github, or maybe a Gitter channel for ad-hoc

> It frustrates me that these projects still use mailing lists and have no sane UI to track issues, submit PRs like Github, or maybe a Gitter channel for ad-hoc chat/questions. I'm not a kernel dev, but I have to ask: what's wrong with mailing lists? Unlike your examples of GitHub and Gitter, they're unencumbered FOSS; this is very important for the Linux kernel, since Linus et al. invented git specifically to remove BitKeeper's proprietary sword of damocles from hanging over the kernel. GitHub is basically BitKeeper 2.0. UI-wise, each dev is free to access their mail however they like. It also has advantages of being federated, accessible offline, easy to write bots for, etc. Presumably some devs have nice UI and automation scripts for their particular workflows; it would certainly be nice if links to such things were collected somewhere, but I don't see any dichotomy between using email and having a nice UI. I certainly find my email UI (Emacs + Mu4e) far nicer than any Web site I've ever seen. As for GitHub pull requests, I've never actually seen the appeal. Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; when I could instead run `git send-email`? I agree that bug tracking seems to be a bit lacking. I've dabbled with things like bugseverywhere, but so far nothing's managed to stick :(

RhodesianHunter 10y ago
Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; Because noone wants to see or deal with your cruft, or that of the thousands of other people also contributing to a large project. Keep it in your own private space until it's accepted as being actually part of the project.
- chriswarbo 10y ago
  > Keep it in your own private space until it's accepted as being actually part of the project. I don't understand; is a clone on my laptop not my own private space?
- marssaxman 10y ago
  I'm not sure what you're talking about here. I don't have commit access to their repository; I just have my local clone. In normal usage, should I want to try fixing a bug or making some other improvement, I'd simply hack on the local repository until I felt satisfied with the change, then mail the diff to some maintainer for review. What "cruft" is there for anyone to see? With the pull-request model, there's a lot of Github-specific folderol necessary to accomplish the same task. Perhaps the pull request process offers some significant benefit for the maintainers, which I haven't been able to see, but whatever it is, it must be weighed against the fact that the complexity of the pull-request process creates a barrier to entry. I can think of two situations where I had enough interest in contributing to a project that I downloaded the code and diagnosed the issue that was bugging me, but gave up when it started to look like it was going to take an hour of extra github hoop-jumping and potentially days of review and testing process just to share my one-line fix. If I'd already been a participant in those projects, dealing with the process might not have been such an issue; but as an outsider, the pull request work flow is a pretty clear "get serious about joining our project, or go away" message. So, I went away. Perhaps those projects will fix those bugs themselves, eventually.
Ajedi32 10y ago
> I'm not a kernel dev, but I have to ask: what's wrong with mailing lists? No way to vote on comments, no formatting or embedded images (which work with all clients, including the web UI), no way to edit comments after you've posted them, no easy way to subscribe/unsubscribe to just one individual thread... need I go on? > Unlike your examples of GitHub and Gitter, they're unencumbered FOSS So use GitLab and RocketChat then. > It also has advantages of being federated, accessible offline, easy to write bots for, etc. Fair point. I think RocketChat is working on federation, and GitLab and RocketChat both have well documented APIs, but for the most part you're correct that email is superior in these points. > I don't see any dichotomy between using email and having a nice UI. I certainly find my email UI (Emacs + Mu4e) far nicer than any Web site I've ever seen. That may be true for you, but not every new developer is going to come into your project with that kind of setup. They'll be reading your plaintext, hard-wrapped emails on Outlook or Gmail while struggling to set up filters so they only have to read emails from the mailing list about threads or topics they're actually interested in. A web UI ensures everyone has a great user experience right out of the gate. > As for GitHub pull requests, I've never actually seen the appeal. All the advantages mentioned in my response to "what's wrong with mailing lists" above, plus inline code review, immediate feedback from CIs, linters, and code coverage analysis tools, and integration with the issue tracking system. > Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; when I could instead run `git send-email`? Personally I've never found the process of creating a fork to be any sort of inconvenience. Maybe you'd be interested in the `hub` CLI though: https://hub.github.com/ https://hub.github.com/
- angersock 10y ago
  You're missing the core point: mailing lists are simple, they require no vendor or stack lock-in, and their quirks are well-known. For a project that needs to last more than 5-10 years, using really boring (fossilized?) communications archive tech is a feature, not a bug.
  - gknoy 10y ago
    Using fossilized communications tech, while ignoring the conveniences embraced by nearly the entire rest of the FOSS community, optimizes for the comfort of the Current Developers, while making it less convenient for New Developers to contribute. New contributions require a person to forego the conveniences which the fossilized tools don't support well, and that friction _might_ contribute to fewer smart people wanting to contribute to your project. Consider as the OSS world's equivalent of a sales funnel. The more I need to deviate from the way I normally work, the less likely I am to want to make that contribution. For a project where the overloading of maintainers is an issue, it might be worth considering the value of making it easier for other people to contribute. Sure, smart people who want to contribute _can_ adapt to the way your project wants them to work, but not all of them will want to jump through that extra hoop.
ben0x539 10y ago
> Linus et al. invented git specifically to remove BitKeeper's proprietary sword of damocles from hanging over the kernel. Didn't he invent it after the sword had fallen and the BitKeeper people withdrew their permission to use it? I get the impression Torvalds is fine with proprietary tools if they're significantly better than the free alternatives.
- mwfunk 10y ago
  This is correct. He wrote git after the BitKeeper relationship went sour. He was fine with it being proprietary software. BitKeeper only became a problem for Linus after the BitKeeper developer took away free licenses for Linux kernel developers, after getting into a kerfluffle with (I believe) Jeremy Allison over the terms of that license.
- chriswarbo 10y ago
  > Didn't he invent it after the sword had fallen and the BitKeeper people withdrew their permission to use it? Yes, perhaps I should have been more specific that the sword (BitKeeper as gatekeeper) was the problem, rather than the "hanging above" (i.e. the threat rather than the actuality).
dgfgfdagasdfgfa 10y ago
> what's wrong with mailing lists? * They have no relation to code. It's difficult to discuss patches. * I don't want to make my email public (mailing lists are public). * The interface for threaded conversations is almost always terrible. * It's trivial to get your concerns ignored. This is much harder will pull requests (but still possible). > UI-wise, each dev is free to access their mail however they like. If they all suck equally, I'm not sure this is a good thing. I certainly don't want to waste my own time coding around the deficiencies of a medium that wasn't built for holding complex conversations. > As for GitHub pull requests, I've never actually seen the appeal. Well, they make it super easy to leave comments on code and iterate before accepting. I've literally never seen this happen quickly via a mailing list: it's either poor quality when it's accepted, or it takes forever to merge. Most of all, though, if I need to figure out how to generate and mail a patch, I'm not going to even bother looking up the mailing list: I know it's not worth my time. This is exactly the type of problem git is good at solving; why resist?
hobarrera 10y ago
You mostly seem to attack GitHub because it's propietary. GP's argument can be applied to GitLab (eg: more "friendly" for new devs), and is FLOSS, and can be self-hosted. Interaction via email is also possible.

RhodesianHunter 10y ago

Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; Because noone wants to see or deal with your cruft, or that of the thousands of other people also contributing to a large project. Keep it in your own private space until it's accepted as being actually part of the project.

chriswarbo 10y ago
> Keep it in your own private space until it's accepted as being actually part of the project. I don't understand; is a clone on my laptop not my own private space?
marssaxman 10y ago
I'm not sure what you're talking about here. I don't have commit access to their repository; I just have my local clone. In normal usage, should I want to try fixing a bug or making some other improvement, I'd simply hack on the local repository until I felt satisfied with the change, then mail the diff to some maintainer for review. What "cruft" is there for anyone to see? With the pull-request model, there's a lot of Github-specific folderol necessary to accomplish the same task. Perhaps the pull request process offers some significant benefit for the maintainers, which I haven't been able to see, but whatever it is, it must be weighed against the fact that the complexity of the pull-request process creates a barrier to entry. I can think of two situations where I had enough interest in contributing to a project that I downloaded the code and diagnosed the issue that was bugging me, but gave up when it started to look like it was going to take an hour of extra github hoop-jumping and potentially days of review and testing process just to share my one-line fix. If I'd already been a participant in those projects, dealing with the process might not have been such an issue; but as an outsider, the pull request work flow is a pretty clear "get serious about joining our project, or go away" message. So, I went away. Perhaps those projects will fix those bugs themselves, eventually.

Ajedi32 10y ago

> I'm not a kernel dev, but I have to ask: what's wrong with mailing lists? No way to vote on comments, no formatting or embedded images (which work with all clients, including the web UI), no way to edit comments after you've posted them, no easy way to subscribe/unsubscribe to just one individual thread... need I go on? > Unlike your examples of GitHub and Gitter, they're unencumbered FOSS So use GitLab and RocketChat then. > It also has advantages of being federated, accessible offline, easy to write bots for, etc. Fair point. I think RocketChat is working on federation, and GitLab and RocketChat both have well documented APIs, but for the most part you're correct that email is superior in these points. > I don't see any dichotomy between using email and having a nice UI. I certainly find my email UI (Emacs + Mu4e) far nicer than any Web site I've ever seen. That may be true for you, but not every new developer is going to come into your project with that kind of setup. They'll be reading your plaintext, hard-wrapped emails on Outlook or Gmail while struggling to set up filters so they only have to read emails from the mailing list about threads or topics they're actually interested in. A web UI ensures everyone has a great user experience right out of the gate. > As for GitHub pull requests, I've never actually seen the appeal. All the advantages mentioned in my response to "what's wrong with mailing lists" above, plus inline code review, immediate feedback from CIs, linters, and code coverage analysis tools, and integration with the issue tracking system. > Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; when I could instead run `git send-email`? Personally I've never found the process of creating a fork to be any sort of inconvenience. Maybe you'd be interested in the `hub` CLI though: https://hub.github.com/ https://hub.github.com/

angersock 10y ago
You're missing the core point: mailing lists are simple, they require no vendor or stack lock-in, and their quirks are well-known. For a project that needs to last more than 5-10 years, using really boring (fossilized?) communications archive tech is a feature, not a bug.
- gknoy 10y ago
  Using fossilized communications tech, while ignoring the conveniences embraced by nearly the entire rest of the FOSS community, optimizes for the comfort of the Current Developers, while making it less convenient for New Developers to contribute. New contributions require a person to forego the conveniences which the fossilized tools don't support well, and that friction _might_ contribute to fewer smart people wanting to contribute to your project. Consider as the OSS world's equivalent of a sales funnel. The more I need to deviate from the way I normally work, the less likely I am to want to make that contribution. For a project where the overloading of maintainers is an issue, it might be worth considering the value of making it easier for other people to contribute. Sure, smart people who want to contribute _can_ adapt to the way your project wants them to work, but not all of them will want to jump through that extra hoop.

ben0x539 10y ago

> Linus et al. invented git specifically to remove BitKeeper's proprietary sword of damocles from hanging over the kernel. Didn't he invent it after the sword had fallen and the BitKeeper people withdrew their permission to use it? I get the impression Torvalds is fine with proprietary tools if they're significantly better than the free alternatives.

mwfunk 10y ago
This is correct. He wrote git after the BitKeeper relationship went sour. He was fine with it being proprietary software. BitKeeper only became a problem for Linus after the BitKeeper developer took away free licenses for Linux kernel developers, after getting into a kerfluffle with (I believe) Jeremy Allison over the terms of that license.
chriswarbo 10y ago
> Didn't he invent it after the sword had fallen and the BitKeeper people withdrew their permission to use it? Yes, perhaps I should have been more specific that the sword (BitKeeper as gatekeeper) was the problem, rather than the "hanging above" (i.e. the threat rather than the actuality).

dgfgfdagasdfgfa 10y ago

> what's wrong with mailing lists? * They have no relation to code. It's difficult to discuss patches. * I don't want to make my email public (mailing lists are public). * The interface for threaded conversations is almost always terrible. * It's trivial to get your concerns ignored. This is much harder will pull requests (but still possible). > UI-wise, each dev is free to access their mail however they like. If they all suck equally, I'm not sure this is a good thing. I certainly don't want to waste my own time coding around the deficiencies of a medium that wasn't built for holding complex conversations. > As for GitHub pull requests, I've never actually seen the appeal. Well, they make it super easy to leave comments on code and iterate before accepting. I've literally never seen this happen quickly via a mailing list: it's either poor quality when it's accepted, or it takes forever to merge. Most of all, though, if I need to figure out how to generate and mail a patch, I'm not going to even bother looking up the mailing list: I know it's not worth my time. This is exactly the type of problem git is good at solving; why resist?

hobarrera 10y ago

You mostly seem to attack GitHub because it's propietary. GP's argument can be applied to GitLab (eg: more "friendly" for new devs), and is FLOSS, and can be self-hosted. Interaction via email is also possible.