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.
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-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.
Emailing patches is just as hard as making pull requests.
Hmm, sounds exactly like a use-case for Base64 and/or mime attachments. Perhaps it's worth persuing this, if there's no existing support?
That's either an argument against encoding patches, or for reading email in Emacs (M-x base64-decode-region). I don't suppose many would take the latter stance ;)
An email client which doesn't do that is broken; why would one use a primary email client which is broken?
(Yeah, it's a rhetorical question: I'm using an app client these days like everyone else, but I hate how broken it is)
In which case, yes, you can set up a personal email address, but that just reduces it to the previously unsolved burden of having to set up another account just to contribute to a project.
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.
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.
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.
The point is that reducing the friction required to contribute to an open source project is a great way to attract new contributors. Using more user-friendly dev tools is a great way to do that, and is therefore something existing maintainers would be wise to consider doing.
Yes. Because that's true. Either you have a good point and manage to convince people in the project, or you have to fork.
Writing irrelevant comments on some news site is not going to convince anyone to spend a combined hundreds to thousands of man-hours work (at the very least) to move kernel development to GitHub or whatever platform you like.
Also notice how you are ranting about tooling in a project you're not contributing to, while the submission here is about something entirely different -- and written by a contributor.
So you're saying we shouldn't discuss this at all? Just shut up and stop trying to convince anyone to adopt a viewpoint I believe would be beneficial to open source projects in the future?
IMO open discussions like this are a good and healthy thing for any community of developers (such as the one on Hacker News) to have. It's a great way to share ideas with each other and collectively come up with ways to improve the open source community. It's not something that should be discouraged.
So don't.
Do you have a single compelling issue why they should switch?
I mean, you can do a lot of amazing stuff in a TUI, but at this point I'm fairly sure that I only like them out of Stockholm syndrome.
Last point aside, these are all in favor of mailing lists, you know.
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.
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.
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.
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.
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.
- 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.
I can't speak for others here, but personally I treat freedom as my first priority: it doesn't matter what features a platform offers if it doesn't offer freedom, because I will not use it if it doesn't offer freedom, therefore I'll never see any of those purported features.
If I have the choice of a) contributing to the latest hippest JS browser framework right away, or b) spending several hours setting up a custom email-based work environment, then contributing to the driver for my bleeding-edge Skylake system, I know what I'm going to choose - despite having way more experience with kernel hacking (in a corporate, GitHub-Enterprise-using environment).
Again, I'd rather have my kernel code written by someone who has respect for others, and doesn't view spending a little time learning how to be productive in a group as 'jumping through hoops to learn the obscure workflow of an old community.'
> If I have the choice of a) contributing to the latest hippest JS browser framework right away, or b) spending several hours setting up a custom email-based work environment, then contributing to the driver for my bleeding-edge Skylake system, I know what I'm going to choose - despite having way more experience with kernel hacking (in a corporate, GitHub-Enterprise-using environment).
That's a-okay by me.
Over time, the number of people who are _willing_ to learn your conventions, versus those who _want_ t o use those conventions, may change. You may have several colleagues (and many more who have not yet contributed) who are willing to use email, but would prefer a web-based collaboration platform.
Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail. Rejecting those out of hand as "not productive" seems a bit strange.
Very true! And certainly not all change is bad, and not all new things are worse than their older analogues.
> Consider that there are more ways to "be productive in a group" than e-mail -- there's a reason many of us in our work lives have transitioned to using Github or similar web-based repo-collaboration tools, rather than e-mail.
True enough, but I wonder how much of that is not because they are fundamentally better but because email has gotten popular. I can't easily review source code via email because I have to wade through meeting invites, corporate communications and recruiter spam.
Honestly, though, GitHub doesn't really give me a whole lot, other than centralised issue tracking and a data store. I never use its git UI; I just use Magit locally. I've actually been thinking about how a team could use commands to manipulate text files in a git repo to manage history for that repo — then one would never need to leave one's editor to manage issues. With a central file server open to users, merges and PRs could just be operations on the repo itself.
My idea's not fully fleshed out, but I think it'd be awesome, and more productive that using GitHub via a web browser.
Strongly disagree. As a general observation, people who don't have the patience to learn community norms generally don't have the patience to follow coding styles or write tests or properly document their code.
Do developers really think that way?
I know if I'm going to invest 50+ hours of my time on an activity then an hour or two to get setup is no big deal.
You...do realize that a patch email and subscribing to a mailing list isn't exactly something that should take "several hours", right?
Mailing lists are a nightmare for newcomers. That's why they progressively disappear.
In this sense, having a developer mailing list is like FizzBuzz for potential contributors- if they can't handle the easy stuff, they definitely won't be able to effectively contribute as software developers to a nontrivial project.
Another nice thing about email is that in practice, it's a slightly more formalized form of communication. Lots of people write terrible emails, but lots more people type terribly written messages into little boxes on web sites. The nature of the medium (in my experience at least) is such that people are much less likely to treat email like chat than they are to treat web forums like chat, and they're much more likely to make an effort to communicate effectively, which is absolutely critical for successful distributed development.
Finally, I think people forget that it's not necessarily a net good for the users of an open source project to have the most frictionless mechanism possible for interacting with or sending patches to the developers of those projects. People who are new to open source, especially if they're new to software development in general, sometimes have this ideal that more community is always better than less community, and more communication is always better than less communication, and more patches from the community are always better than fewer patches from the community, but I don't think this is true at all. It's very dependent on how the project is run and the goals of its developers. It can be a net good for the whole project to have some hoops that people have to jump through before they can start pestering the developers with patches, and email is about the most trivial hoop there is. Lots of projects intentionally erect many more barriers than that, and that's not necessarily a bad thing. The goal of most open source projects is to produce high-quality shared software, not to be a social experiment with the lowest possible bar for involvement.
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).
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/