5 ms·

My biggest concern about this is that now it is in Emacs, there's no easy way to contribute to it, or follow development. Previously it was on GitHub and there

My biggest concern about this is that now it is in Emacs, there's no easy way to contribute to it, or follow development. Previously it was on GitHub and there was zero friction to contributing other than figuring out your elisp changes. But now, I think that Issues in the github site are discouraged, and so there will be no convenient way of watching issues and feature requests raised against the project, or of following discussion of proposed patches and code review. In principle of course, these things are possible by using old issue tracking applications and following often dysfunctional/cantankerous discussions in a email list, both of whose scope is the whole of emacs.

db48x 4y ago
Email is Email. Either you reply to an email from Github or an email from the mailing list.
- Myrmornis 4y ago
  You don't use GitHub/GitLab/SourceHut/Codeberg by "replying to emails". You use them by: - pushing branches to your own fork so that others can see your work while it's in draft form - opening PRs against the main project, and writing a nice PR introduction describing the changes that you've made, their background, and motivation, drawbacks and hesitations, etc. - participating in a feedback conversation with the maintainers and other developers with comments attached to specific lines in the code (at a specific revision), as well as attached at diff level - having the project CI run against your branch to check that all tests pass, across a collection of different OSs and architectures. (You can also run their CI in your own fork to check it works there before even opening a PR). - opening Issues, and discussing with other developers - having the ability to write your text comments along with images, videos, and syntax-highlighted code fragments. - and many other things
  - rekado 4y ago
    You can still do that with your fork on a forge. And all that other stuff relating to communication (commenting on specific lines of a change set, writing a nice introduction describing the changes you've made, discussing with other developers, etc.) is possible just as well with a patch-via-email workflow.
  - db48x 4y ago
    No, you can do all of that on the mailing list too. - Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing. - Send an email to the development mailing list, making sure to write a nice introduction describing the changes that you’ve made, their background, motivation, drawbacks, hesitations, and so on. - participate in feedback conversations with the maintainers and other developers with comments situated next to quotations of specific lines of code from specific revisions or specific diff hunks. - Just run “make check”. 99% of all of the code in Emacs is written in Emacs Lisp, which is platform–independent. If the tests pass on your own computer you can rest assured that they will pass on everyone else’s too. - sending emails to ask questions and discuss them with other developers - feel free to include any type of media in your emails, all but one participant in the mailing list can view them - and many other things
    - count 4y ago
      > - Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing. This is the 'we have PRs at home' point of view. It's not WRONG, but I think it does miss the point. 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer. The project is well within it's rights to do so, but, there's a reason GitHub specifically is super popular, and it's mostly to provide structure and avoid the pain in the neck that the 'do it by email' and 'just use these different things' approach while collaborating.
      - db48x 4y ago
        > 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer. Following the herd is definitely the wrong answer.
        cercatrova 4y ago
        Well, GNU does make both.
  - mrelectric 4y ago
    I get your point but why do you think that's what they need and that you're the target audience in the fist place?
- st3fan 4y ago
rout39574 4y ago
How many contributions did you have to eglot before it was included?
- Myrmornis 4y ago
  4 PRs and 3 Issues
tgerdin 4y ago
Probably says more about the Emacs development process than Eglot itself. But as it stands, the copyright assignment is non-negotiable I guess.
tmtvl 4y ago
Eh, I find GNU Savannah easy enough to navigate and to track changes through it. It may not have an integrated issue tracker, but that's what the mailing list and GNU debbugs are for.
- dan-robertson 4y ago
  I don’t understand how this comment actually responds to any of the issues the parent raises? I think they would have made a perfectly good comment if they hadn’t spelled out the issues with the non-GitHub system but they seem to have taken the time to address many of the things you write about in advance (unless they edited that part in after your comment). Fwiw I also think you’re missing the point about the increased barrier to entry. I suppose one could make arguments from first principles about which platform has the higher barrier to entry but actual people don’t start from first principles – they are much more likely to be familiar with GitHub (I have weaker priors for eglot contributors but I still expect potential new contributors to be more familiar with GitHub).
  - tmtvl 4y ago
    I must have failed my reading comprehension. Sorry, it's been a long day.
parasti 4y ago
That's a problem with using Github, not a problem with Emacs development.
- dan-robertson 4y ago
  The problem with GitHub is that it’s zero friction to contribute? I don’t understand what you’re saying.
  - parasti 4y ago
    Just thinking out loud. Github is great. It is also a proprietary, centralized, Microsoft owned service. The "problem" with Github and the enormous popularity of Github is that by not using it, an open source project is perceived to be harder to contribute to.
ashton314 4y ago
I’m trying to think: is there a package that was added to Emacs core that’s continued to have good development? Does bundling eglot mean that eglot releases are now tied to Emacs releases?
- dan-robertson 4y ago
  Maybe org-mode?

db48x 4y ago

Email is Email. Either you reply to an email from Github or an email from the mailing list.

Myrmornis 4y ago
You don't use GitHub/GitLab/SourceHut/Codeberg by "replying to emails". You use them by: - pushing branches to your own fork so that others can see your work while it's in draft form - opening PRs against the main project, and writing a nice PR introduction describing the changes that you've made, their background, and motivation, drawbacks and hesitations, etc. - participating in a feedback conversation with the maintainers and other developers with comments attached to specific lines in the code (at a specific revision), as well as attached at diff level - having the project CI run against your branch to check that all tests pass, across a collection of different OSs and architectures. (You can also run their CI in your own fork to check it works there before even opening a PR). - opening Issues, and discussing with other developers - having the ability to write your text comments along with images, videos, and syntax-highlighted code fragments. - and many other things
- rekado 4y ago
  You can still do that with your fork on a forge. And all that other stuff relating to communication (commenting on specific lines of a change set, writing a nice introduction describing the changes you've made, discussing with other developers, etc.) is possible just as well with a patch-via-email workflow.
- db48x 4y ago
  No, you can do all of that on the mailing list too. - Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing. - Send an email to the development mailing list, making sure to write a nice introduction describing the changes that you’ve made, their background, motivation, drawbacks, hesitations, and so on. - participate in feedback conversations with the maintainers and other developers with comments situated next to quotations of specific lines of code from specific revisions or specific diff hunks. - Just run “make check”. 99% of all of the code in Emacs is written in Emacs Lisp, which is platform–independent. If the tests pass on your own computer you can rest assured that they will pass on everyone else’s too. - sending emails to ask questions and discuss them with other developers - feel free to include any type of media in your emails, all but one participant in the mailing list can view them - and many other things
  - count 4y ago
    > - Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing. This is the 'we have PRs at home' point of view. It's not WRONG, but I think it does miss the point. 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer. The project is well within it's rights to do so, but, there's a reason GitHub specifically is super popular, and it's mostly to provide structure and avoid the pain in the neck that the 'do it by email' and 'just use these different things' approach while collaborating.
    - db48x 4y ago
      > 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer. Following the herd is definitely the wrong answer.
      - cercatrova 4y ago
        Well, GNU does make both.
- mrelectric 4y ago
  I get your point but why do you think that's what they need and that you're the target audience in the fist place?
st3fan 4y ago

rout39574 4y ago

How many contributions did you have to eglot before it was included?

Myrmornis 4y ago
4 PRs and 3 Issues

tgerdin 4y ago

Probably says more about the Emacs development process than Eglot itself. But as it stands, the copyright assignment is non-negotiable I guess.

tmtvl 4y ago

Eh, I find GNU Savannah easy enough to navigate and to track changes through it. It may not have an integrated issue tracker, but that's what the mailing list and GNU debbugs are for.

dan-robertson 4y ago
I don’t understand how this comment actually responds to any of the issues the parent raises? I think they would have made a perfectly good comment if they hadn’t spelled out the issues with the non-GitHub system but they seem to have taken the time to address many of the things you write about in advance (unless they edited that part in after your comment). Fwiw I also think you’re missing the point about the increased barrier to entry. I suppose one could make arguments from first principles about which platform has the higher barrier to entry but actual people don’t start from first principles – they are much more likely to be familiar with GitHub (I have weaker priors for eglot contributors but I still expect potential new contributors to be more familiar with GitHub).
- tmtvl 4y ago
  I must have failed my reading comprehension. Sorry, it's been a long day.

parasti 4y ago

That's a problem with using Github, not a problem with Emacs development.

dan-robertson 4y ago
The problem with GitHub is that it’s zero friction to contribute? I don’t understand what you’re saying.
- parasti 4y ago
  Just thinking out loud. Github is great. It is also a proprietary, centralized, Microsoft owned service. The "problem" with Github and the enormous popularity of Github is that by not using it, an open source project is perceived to be harder to contribute to.

ashton314 4y ago

I’m trying to think: is there a package that was added to Emacs core that’s continued to have good development? Does bundling eglot mean that eglot releases are now tied to Emacs releases?

dan-robertson 4y ago
Maybe org-mode?