9 ms·

> 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 c

by 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.
  - zeveb 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. I think I'd rather not have my kernel code written by someone who is afraid to use an email client. Email is not, FWIW, fossilized. It's far superior to GitHub or Slack, because it's decentralised and truly free.
    - vehementi 10y ago
      Could you show your work? You're valuing "decentralied and truly free" as significantly more valuable than (far superior to) the sum total of GitHub Slack features. Could you list out the GitHub Slack features that you considered (and which ones you didn't consider) and your heuristic for their value and how they all combine to be much, much less valuable than decentralized/free?
      - zeveb 10y ago
        Email: - multiple clients on multiple platforms - multiple clients on emacs (e.g. Gnus, mu4e, NotMuch) - does not require a browser, ever - does not require executing untrusted code on my computer, ever - open protocols - multiple servers on multiple platforms - federated Github, Slack et. al.: - may have a decent text-only client (e.g. there's a Slack mode for emacs, and there are some GitHub clients out there, which may or may not be convenient) - strongly encourage and sometimes mandate use of a browser with execution of untrusted code allowed - protocols controlled by a single organisation, with no possibility to add functionality on the server side - servers controlled by a single organisation - no federation - fundamentally proprietary What I value: freedom; TUI clients; emacs clients; open protocols; being able to run my own service.
nontrivialkk88 10y ago
> No way to vote on comments Good. Speak your piece if you have something to contribute. It's easy to game upvotes; oh look lots of upvotes... oh it's a pointless fluff comment or a flame. Above all, that stuff adds complexity to the system, and no one has shown the value is real versus perceived. > No way to edit comments People should consider what they're about to share. Editing is like starting a company and figuring out your business model after you "reach scale". Having to think before you say something is not a bad idea. > So use Gitlab and rocketchat then Yes, make everyone else move over to these new things! Because needing an email address isn't enough. We need accounts with every service there is! And we need more UI's distracting us with notification bubbles! And let's get all these devs to learn all these new tools. Rather than focusing on producing useful output. Sounds good.
- geofft 10y ago
  Speaking as someone who has gotten a small number of patches into the kernel (via email, naturally), the implication that sending patches by email requires no additional accounts or tools or learning is a false one. Sending patches by email requires an email setup that works. You have, loosely, three options: you can send it in your normal client, you can set up `git send-email` to submit over SMTP, or you can set up `git imap-send` to get it into your normal client's drafts folder. If you choose the first one, your client has to preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact. If you choose the second two, git has to be able to auth to your email server, and nothing else along the way can break the byte-for-byte integrity of your email. Each of these is tricky in various ways; see https://www.kernel.org/doc/Documentation/process/email-clients.rst https://www.kernel.org/doc/Documentation/process/email-clien... for a discussion. (It turns out that email between humans does not depend on byte-for-byte integrity of whitespace.) That's a lot of reading and fiddling for devs who are busy trying to produce useful output! I recall that if your current email address is behind Microsoft Exchange, you simply can't use it for patch submission - the Exchange outgoing SMTP server does something weird with spaces, even if you don't use Outlook and connect directly to it with git send-email. Now, certainly that might be Exchange's fault, but it doesn't change the fact that you'll need to get a new account to submit patches.
gumby 10y ago
> A web UI ensures everyone has a great user experience right out of the gate. That may be true for you, but it's in no way as universal as you seem to think. I have a productive workflow (that gives me enough free time to comment on HN :-) that is effective for the several things I work on during the day (a couple of development projects, some management, etc). Hopping over to some web silo doesn't speed things up for me. The real reason people stick to the current model is because it works. A common baseline lets people use the tools that work for them rather than trying to cram everyone into the same procrustean tools space.
- Ajedi32 10y ago
  Yeah, I realize a lot of devs have already have their own setups that work extremely well for them. Unfortunately anytime you transition to a new tool you're obviously going to break _someone's_ workflow. That said, switching to something like GitHub doesn't necessarily mean developers all _have_ to use exactly the same workflow. For example, if you're more comfortable in the command line, there are tools like [hub][1] and [git-gitlab][2] available which let you perform common tasks in GitHub/GitLab using the CLI. I just think that long-term it's better to have a good baseline user experience that devs can then extend with their own personal tools if they choose than to have a not-so-great one that _requires_ you to extend it with your own tools before it's anywhere near as good as what a well-designed Web UI provides out-of-the-box; even if in the short-term that means breaking some dev's workflows. Obviously that doesn't mean you shouldn't try to maintain compatibility with developer's existing workflows wherever possible though. For example, GitLab and GitHub both let you reply to issues by email, and RocketChat has an IRC plugin that lets you connect RocketChat rooms to an IRC channel. [1]: https://github.com/github/hub https://github.com/github/hub [2]: https://github.com/numa08/git-gitlab https://github.com/numa08/git-gitlab
  - gumby 10y ago
    I feel like you're addressing a nonissue. If you want to start your own project, you can set the standards for development process, coding standards, language, etc. If I don't like those choices it's no big deal and no slur on you: I'll just work on what I want and folks who agree will be delighted to work with you. But your note feels like you're saying "why don't the kernel dev switch to Ruby?" Of course when I say it that way it sounds absurd, but really it's simply an equivalent.
lightedman 10y ago
"A web UI ensures everyone has a great user experience right out of the gate." I have a few blind users who would heartily disagree with this point considering most 'modern' web UIs totally break any sort of reader usability.
- Ajedi32 10y ago
  Yeah sorry, I should have phrased that as "a well-designed web UI". It's certainly not impossible to create a modern web UI which works well with screen readers.
Sir_Cmpwn 10y ago
>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? Last point aside, these are all in favor of mailing lists, you know.
- Ajedi32 10y ago
  What? Why? All of those are extremely useful features I find myself missing whenever I'm forced to use a platform which doesn't have them.
  - Sir_Cmpwn 10y ago
    It's not for your sake, it's for the sake of the maintainers that have to deal with your code.
    - Ajedi32 10y ago
      Why would allowing developers (maintainers included) to post, vote on, and edit formatted markdown comments make it harder for maintainers to deal with my code?
      - Sir_Cmpwn 10y ago
        Because voting isn't important and plaintext is easier to deal with than markdown. Plaintext works in a terminal and with embedded patches and inline replies and so on. You don't grok it, that doesn't make it worse.
        Ajedi32 10y ago
        > Because voting isn't important Voting is absolutely important. It makes it easier to gauge the community's reaction to issues, PRs, and comments, and cuts down on "me too" type comments which might otherwise clutter issues. > plaintext is easier to deal with than markdown Markdown _is_ plain text. I've been writing all my comments up to this point in Markdown. Did you notice? > Plaintext works in a terminal and with embedded patches and inline replies and so on. So does Markdown. The difference is that Markdown can _also_ be rendered as pretty, fully-formatted text in a web browser.
deleted 10y ago
[deleted]
nullc 10y ago
> 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 Can you cite any study evidence that suggests that these are helpful features in this context (or even that they aren't massively harmful? Comment voting in particular appears to be an especially strong source of toxicity and online forums that feature it prominently have a pretty reliably history of going down in flames after a few years).
- striking 10y ago
  ... he wrote, on a forum that's existed for 10 years now, with few problems with toxicity.

by Ajedi32 10y ago

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.
- zeveb 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. I think I'd rather not have my kernel code written by someone who is afraid to use an email client. Email is not, FWIW, fossilized. It's far superior to GitHub or Slack, because it's decentralised and truly free.
  - vehementi 10y ago
    Could you show your work? You're valuing "decentralied and truly free" as significantly more valuable than (far superior to) the sum total of GitHub Slack features. Could you list out the GitHub Slack features that you considered (and which ones you didn't consider) and your heuristic for their value and how they all combine to be much, much less valuable than decentralized/free?
    - zeveb 10y ago
      Email: - multiple clients on multiple platforms - multiple clients on emacs (e.g. Gnus, mu4e, NotMuch) - does not require a browser, ever - does not require executing untrusted code on my computer, ever - open protocols - multiple servers on multiple platforms - federated Github, Slack et. al.: - may have a decent text-only client (e.g. there's a Slack mode for emacs, and there are some GitHub clients out there, which may or may not be convenient) - strongly encourage and sometimes mandate use of a browser with execution of untrusted code allowed - protocols controlled by a single organisation, with no possibility to add functionality on the server side - servers controlled by a single organisation - no federation - fundamentally proprietary What I value: freedom; TUI clients; emacs clients; open protocols; being able to run my own service.

nontrivialkk88 10y ago

> No way to vote on comments Good. Speak your piece if you have something to contribute. It's easy to game upvotes; oh look lots of upvotes... oh it's a pointless fluff comment or a flame. Above all, that stuff adds complexity to the system, and no one has shown the value is real versus perceived. > No way to edit comments People should consider what they're about to share. Editing is like starting a company and figuring out your business model after you "reach scale". Having to think before you say something is not a bad idea. > So use Gitlab and rocketchat then Yes, make everyone else move over to these new things! Because needing an email address isn't enough. We need accounts with every service there is! And we need more UI's distracting us with notification bubbles! And let's get all these devs to learn all these new tools. Rather than focusing on producing useful output. Sounds good.

geofft 10y ago
Speaking as someone who has gotten a small number of patches into the kernel (via email, naturally), the implication that sending patches by email requires no additional accounts or tools or learning is a false one. Sending patches by email requires an email setup that works. You have, loosely, three options: you can send it in your normal client, you can set up `git send-email` to submit over SMTP, or you can set up `git imap-send` to get it into your normal client's drafts folder. If you choose the first one, your client has to preserve spaces, tabs, linebreaks, and everything else byte-for-byte intact. If you choose the second two, git has to be able to auth to your email server, and nothing else along the way can break the byte-for-byte integrity of your email. Each of these is tricky in various ways; see https://www.kernel.org/doc/Documentation/process/email-clients.rst https://www.kernel.org/doc/Documentation/process/email-clien... for a discussion. (It turns out that email between humans does not depend on byte-for-byte integrity of whitespace.) That's a lot of reading and fiddling for devs who are busy trying to produce useful output! I recall that if your current email address is behind Microsoft Exchange, you simply can't use it for patch submission - the Exchange outgoing SMTP server does something weird with spaces, even if you don't use Outlook and connect directly to it with git send-email. Now, certainly that might be Exchange's fault, but it doesn't change the fact that you'll need to get a new account to submit patches.

gumby 10y ago

> A web UI ensures everyone has a great user experience right out of the gate. That may be true for you, but it's in no way as universal as you seem to think. I have a productive workflow (that gives me enough free time to comment on HN :-) that is effective for the several things I work on during the day (a couple of development projects, some management, etc). Hopping over to some web silo doesn't speed things up for me. The real reason people stick to the current model is because it works. A common baseline lets people use the tools that work for them rather than trying to cram everyone into the same procrustean tools space.

Ajedi32 10y ago
Yeah, I realize a lot of devs have already have their own setups that work extremely well for them. Unfortunately anytime you transition to a new tool you're obviously going to break _someone's_ workflow. That said, switching to something like GitHub doesn't necessarily mean developers all _have_ to use exactly the same workflow. For example, if you're more comfortable in the command line, there are tools like [hub][1] and [git-gitlab][2] available which let you perform common tasks in GitHub/GitLab using the CLI. I just think that long-term it's better to have a good baseline user experience that devs can then extend with their own personal tools if they choose than to have a not-so-great one that _requires_ you to extend it with your own tools before it's anywhere near as good as what a well-designed Web UI provides out-of-the-box; even if in the short-term that means breaking some dev's workflows. Obviously that doesn't mean you shouldn't try to maintain compatibility with developer's existing workflows wherever possible though. For example, GitLab and GitHub both let you reply to issues by email, and RocketChat has an IRC plugin that lets you connect RocketChat rooms to an IRC channel. [1]: https://github.com/github/hub https://github.com/github/hub [2]: https://github.com/numa08/git-gitlab https://github.com/numa08/git-gitlab
- gumby 10y ago
  I feel like you're addressing a nonissue. If you want to start your own project, you can set the standards for development process, coding standards, language, etc. If I don't like those choices it's no big deal and no slur on you: I'll just work on what I want and folks who agree will be delighted to work with you. But your note feels like you're saying "why don't the kernel dev switch to Ruby?" Of course when I say it that way it sounds absurd, but really it's simply an equivalent.

lightedman 10y ago

"A web UI ensures everyone has a great user experience right out of the gate." I have a few blind users who would heartily disagree with this point considering most 'modern' web UIs totally break any sort of reader usability.

Ajedi32 10y ago
Yeah sorry, I should have phrased that as "a well-designed web UI". It's certainly not impossible to create a modern web UI which works well with screen readers.

Sir_Cmpwn 10y ago

>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? Last point aside, these are all in favor of mailing lists, you know.

Ajedi32 10y ago
What? Why? All of those are extremely useful features I find myself missing whenever I'm forced to use a platform which doesn't have them.
- Sir_Cmpwn 10y ago
  It's not for your sake, it's for the sake of the maintainers that have to deal with your code.
  - Ajedi32 10y ago
    Why would allowing developers (maintainers included) to post, vote on, and edit formatted markdown comments make it harder for maintainers to deal with my code?
    - Sir_Cmpwn 10y ago
      Because voting isn't important and plaintext is easier to deal with than markdown. Plaintext works in a terminal and with embedded patches and inline replies and so on. You don't grok it, that doesn't make it worse.
      - Ajedi32 10y ago
        > Because voting isn't important Voting is absolutely important. It makes it easier to gauge the community's reaction to issues, PRs, and comments, and cuts down on "me too" type comments which might otherwise clutter issues. > plaintext is easier to deal with than markdown Markdown _is_ plain text. I've been writing all my comments up to this point in Markdown. Did you notice? > Plaintext works in a terminal and with embedded patches and inline replies and so on. So does Markdown. The difference is that Markdown can _also_ be rendered as pretty, fully-formatted text in a web browser.

deleted 10y ago

[deleted]

nullc 10y ago

> 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 Can you cite any study evidence that suggests that these are helpful features in this context (or even that they aren't massively harmful? Comment voting in particular appears to be an especially strong source of toxicity and online forums that feature it prominently have a pretty reliably history of going down in flames after a few years).

striking 10y ago
... he wrote, on a forum that's existed for 10 years now, with few problems with toxicity.