5 ms·

It sounds like the author wants basically everything about how Emacs is developed to change in order to better fit their ideas about what open source looks like

It sounds like the author wants basically everything about how Emacs is developed to change in order to better fit their ideas about what open source looks like. There are plenty of established projects that don't use a "pull request" workflow, Emacs only recently migrated to Git; I don't have the discussion from ESR around migrating Emacs to Git handy, but it was a pretty slow process to "bring Emacs into the 21st century" and encourage contributions from new devs. There is simply no way the entire development workflow would change based on this critique. Never mind the fact that Emacs is RMS' baby, the suggestions are so far-fetched as to be laughable. > the vast majority of modern software developers do not want to use email as their communication channel This sounds more like "the vast majority of software developers like me" and I'm not sure how much value there is in debating something like that. Mark me down for "disagree". I have, in the past, skipped over projects when the only means of contribution or discussion is "sign up for our Slack/Gitter/etc. channel".

616c 10y ago
The problem is, and I think in the case of Github he makes his rationale plain and clear: > I don’t think it would be right for Emacs to use github.com. I don’t even think it is right for ENSIME to use github, but I’m scared of moving in-case we lose contributor momentum. The FSF gave github.com a bad score and it’s not libre, which makes me nervous. This is what scares me about the power of GH too. But let's be honest, as this came up with Stuart Sierra yesterday as well in his post on open source rewards stupid bug fixes and not hard work. https://stuartsierra.com/2016/07/18/apathy-of-the-commons https://stuartsierra.com/2016/07/18/apathy-of-the-commons If the work is boring, people won't do it. A corollary: if the tooling sucks, people avoid the tooling, and then things stay on the backburner and never complete. I hate the whole Slack/Gitter/IM channel as well, but the idea of avoiding tooling (e.g. git), which did take Emacs forever, leads to far less contributors like me. Can we at least work on documenting contributor workflow? How do I build an Emacs test environment and harness system? These things must be bookmarked to emacs-devel and other mailing lists on MARC archives and what-not, as I have yet to find even good blog posts (not that I say that as a standard, but in this case more of what I don't want) of how to set this up. I do not expect a Github wiki linking to a Gitter channel about setting up a Docker dev containter for emacs-25.x, but can we at least have better tooling for pulling from git repos and running the test suite? Document it in the manual? https://duckduckgo.com/html?q=emacs%20build%20environment https://duckduckgo.com/html?q=emacs%20build%20environment
- catern 10y ago
  >Can we at least work on documenting contributor workflow? It is documented. Look at the file "CONTRIBUTE" in the root of the Emacs source. That file is also cited in the manual: https://www.gnu.org/software/emacs/manual/html_node/emacs/Contributing.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Co... And that manual page is the first Google result for "contributing to emacs".
  - 616c 10y ago
    Thanks for taking the time to respond. This nice, but I have screwed around with open source for a long time. So, things like: > Ref: The "Tips" Appendix in the Emacs Lisp Reference. Example Novice (not me in this case): How do I get to that? > After you have downloaded the repository source, you should read the file INSTALL.REPO for build instructions (they differ to some extent from a normal build). > Ref: http://savannah.gnu.org/projects/emacs http://savannah.gnu.org/projects/emacs Example Novice (not me in this case): What am I downloading from there? I guess I will go visit that page. > See the existing ChangeLog files for format and content. Note that, unlike some other projects, we do require ChangeLogs also for documentation, i.e. Texinfo files. > Ref: "Change Log Concepts" node of the GNU Coding Standards Info Manual, for how to write good log entries. Example Novice (not me in this case): What the hell is Texinfo? My point is this is a good high-level view. It asks me to visit half a dozen different manuals and asks I fill out a CLA. I am not saying this is even god awful by open source standards, it is good. The problem is I am on the tail end of Linux/FLOSS culture, where a lot of people want more tooling and less learning. I know that is asking a lot. I give counter-examples in this space (Fedora, Mozilla, Start-a-flame-with-Node-NPM-dev-groups) and more focus on onboarding and get on the ground running. Re your point on Google, I am embarassed. I looked up on DDG, and with !g for Google "emacs volunteer" "emacs hack" initially and never found these documents at first. I later did, but cloning the code is not where I see the issue here. This stuff does not inhibit me from contributing. The problem with Linux and emacs is I must spam many thousands of people with git patches via email, and I want a way to build a reliable system in a VM or container without shitting all over my system emacs (it is a shell and editor for me) and finding a mentor so I do not get yelled at for spamming THOUSANDS of veteran Emacs devs I respect. I do not want every to use the damn Vagrantfile, but I would an emacs novice devel list or wiki or anything where I can build up to being one of those people, with simplified environments, and admit I need training wheels to contribute to one of the oldest and most important active FLOSS projects in existence. I know I demand a lot, but you seem to know this stuff. In my position, would you contribute a patch without anyone else helping you just given this material and not expect nastygrams back? Yes, we have a CONTRIBUTE page that links to a dozen manuals is a good start, but is the kind of reaction that leads to the blog posts we see here. I do not mean to target you, but git clone I can do. Moving from that to being a member of emacs-devel that is not yelled at to the stop screwing up is different. I find that more intimidating and think that is something worth focusing on.
flukus 10y ago
Can anyone explain slack to me? It just seems like a shitty reinvention of IRC.
- MichaelGG 10y ago
  Doesn't require an IRC client, looks slick, has rich text, and integrations with other platforms. Biggest thing is that it doesn't need an IRC server. It could have been made with IRC underneath, but you'd want an intermediate layer to retain messages and so on.
  - flukus 10y ago
    There are web based IRC clients. IRC can integrate with other platforms pretty easily. IRC doesn't require setting up your own server. Being able to setup your own server is a benefit, not a negative. Much like twitter it seems to be another regressions from an open internet to corporate control. The only positive I can see is rich text, but that has extremely limited value in a chat program. History is nice too but IME too painful to use (scroll, load, scroll, load, scroll, load) to be of any practical benefit.
    - marssaxman 10y ago
      Rich text is a pretty strong negative, for me!
    - MichaelGG 10y ago
      I'd love to agree. But with IRC you've no guarantee, for instance, that an offline user will receive notifications when they sign in (plus multi client handling). Slack has search for history, which is huge. No more "eh we talked about it". Onprem is great. But it's a hindrance for quick adoption. I'd love if an open system would win. I've no love for Slack and don't use it. (Have used hipchat; what a UI mess like all of their products.) But I guess no one stepped up with an IRC-based platform that could compete.
      - flukus 10y ago
jjrh 10y ago
> This sounds more like "the vast majority of software developers like me" and I'm not sure how much value there is in debating something like that. Mark me down for "disagree". I'm not a fan of this, but lets not act like A LOT of new projects aren't going in this direction because they are. > the suggestions are so far-fetched as to be laughable. Yeah, considering git still is a source of contention on the list changing anything in their process seems nuts. > I have, in the past, skipped over projects when the only means of contribution or discussion is "sign up for our Slack/Gitter/etc. channel". I understand - and i'm not a fan, but that goes both ways - lot of folks have skipped over projects when the primary forms of communication are mailing lists/irc - stuff that is foreign to them or seems like a hassle. I do think that stuff like emacs does get hurt by their processes - moving to git was a big step. The devel list is less than welcoming and at times very hostile.

616c 10y ago

The problem is, and I think in the case of Github he makes his rationale plain and clear: > I don’t think it would be right for Emacs to use github.com. I don’t even think it is right for ENSIME to use github, but I’m scared of moving in-case we lose contributor momentum. The FSF gave github.com a bad score and it’s not libre, which makes me nervous. This is what scares me about the power of GH too. But let's be honest, as this came up with Stuart Sierra yesterday as well in his post on open source rewards stupid bug fixes and not hard work. https://stuartsierra.com/2016/07/18/apathy-of-the-commons https://stuartsierra.com/2016/07/18/apathy-of-the-commons If the work is boring, people won't do it. A corollary: if the tooling sucks, people avoid the tooling, and then things stay on the backburner and never complete. I hate the whole Slack/Gitter/IM channel as well, but the idea of avoiding tooling (e.g. git), which did take Emacs forever, leads to far less contributors like me. Can we at least work on documenting contributor workflow? How do I build an Emacs test environment and harness system? These things must be bookmarked to emacs-devel and other mailing lists on MARC archives and what-not, as I have yet to find even good blog posts (not that I say that as a standard, but in this case more of what I don't want) of how to set this up. I do not expect a Github wiki linking to a Gitter channel about setting up a Docker dev containter for emacs-25.x, but can we at least have better tooling for pulling from git repos and running the test suite? Document it in the manual? https://duckduckgo.com/html?q=emacs%20build%20environment https://duckduckgo.com/html?q=emacs%20build%20environment

catern 10y ago
>Can we at least work on documenting contributor workflow? It is documented. Look at the file "CONTRIBUTE" in the root of the Emacs source. That file is also cited in the manual: https://www.gnu.org/software/emacs/manual/html_node/emacs/Contributing.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Co... And that manual page is the first Google result for "contributing to emacs".
- 616c 10y ago
  Thanks for taking the time to respond. This nice, but I have screwed around with open source for a long time. So, things like: > Ref: The "Tips" Appendix in the Emacs Lisp Reference. Example Novice (not me in this case): How do I get to that? > After you have downloaded the repository source, you should read the file INSTALL.REPO for build instructions (they differ to some extent from a normal build). > Ref: http://savannah.gnu.org/projects/emacs http://savannah.gnu.org/projects/emacs Example Novice (not me in this case): What am I downloading from there? I guess I will go visit that page. > See the existing ChangeLog files for format and content. Note that, unlike some other projects, we do require ChangeLogs also for documentation, i.e. Texinfo files. > Ref: "Change Log Concepts" node of the GNU Coding Standards Info Manual, for how to write good log entries. Example Novice (not me in this case): What the hell is Texinfo? My point is this is a good high-level view. It asks me to visit half a dozen different manuals and asks I fill out a CLA. I am not saying this is even god awful by open source standards, it is good. The problem is I am on the tail end of Linux/FLOSS culture, where a lot of people want more tooling and less learning. I know that is asking a lot. I give counter-examples in this space (Fedora, Mozilla, Start-a-flame-with-Node-NPM-dev-groups) and more focus on onboarding and get on the ground running. Re your point on Google, I am embarassed. I looked up on DDG, and with !g for Google "emacs volunteer" "emacs hack" initially and never found these documents at first. I later did, but cloning the code is not where I see the issue here. This stuff does not inhibit me from contributing. The problem with Linux and emacs is I must spam many thousands of people with git patches via email, and I want a way to build a reliable system in a VM or container without shitting all over my system emacs (it is a shell and editor for me) and finding a mentor so I do not get yelled at for spamming THOUSANDS of veteran Emacs devs I respect. I do not want every to use the damn Vagrantfile, but I would an emacs novice devel list or wiki or anything where I can build up to being one of those people, with simplified environments, and admit I need training wheels to contribute to one of the oldest and most important active FLOSS projects in existence. I know I demand a lot, but you seem to know this stuff. In my position, would you contribute a patch without anyone else helping you just given this material and not expect nastygrams back? Yes, we have a CONTRIBUTE page that links to a dozen manuals is a good start, but is the kind of reaction that leads to the blog posts we see here. I do not mean to target you, but git clone I can do. Moving from that to being a member of emacs-devel that is not yelled at to the stop screwing up is different. I find that more intimidating and think that is something worth focusing on.

flukus 10y ago

Can anyone explain slack to me? It just seems like a shitty reinvention of IRC.

MichaelGG 10y ago
Doesn't require an IRC client, looks slick, has rich text, and integrations with other platforms. Biggest thing is that it doesn't need an IRC server. It could have been made with IRC underneath, but you'd want an intermediate layer to retain messages and so on.
- flukus 10y ago
  There are web based IRC clients. IRC can integrate with other platforms pretty easily. IRC doesn't require setting up your own server. Being able to setup your own server is a benefit, not a negative. Much like twitter it seems to be another regressions from an open internet to corporate control. The only positive I can see is rich text, but that has extremely limited value in a chat program. History is nice too but IME too painful to use (scroll, load, scroll, load, scroll, load) to be of any practical benefit.
  - marssaxman 10y ago
    Rich text is a pretty strong negative, for me!
  - MichaelGG 10y ago
    I'd love to agree. But with IRC you've no guarantee, for instance, that an offline user will receive notifications when they sign in (plus multi client handling). Slack has search for history, which is huge. No more "eh we talked about it". Onprem is great. But it's a hindrance for quick adoption. I'd love if an open system would win. I've no love for Slack and don't use it. (Have used hipchat; what a UI mess like all of their products.) But I guess no one stepped up with an IRC-based platform that could compete.
    - flukus 10y ago

jjrh 10y ago

> This sounds more like "the vast majority of software developers like me" and I'm not sure how much value there is in debating something like that. Mark me down for "disagree". I'm not a fan of this, but lets not act like A LOT of new projects aren't going in this direction because they are. > the suggestions are so far-fetched as to be laughable. Yeah, considering git still is a source of contention on the list changing anything in their process seems nuts. > I have, in the past, skipped over projects when the only means of contribution or discussion is "sign up for our Slack/Gitter/etc. channel". I understand - and i'm not a fan, but that goes both ways - lot of folks have skipped over projects when the primary forms of communication are mailing lists/irc - stuff that is foreign to them or seems like a hassle. I do think that stuff like emacs does get hurt by their processes - moving to git was a big step. The devel list is less than welcoming and at times very hostile.