I think it would be great if the development of Org has moved to Gitlab or GitHub, i.e. simplified the contribution process.
Perhaps it would make it more familiar, but I don't think it would really simplify it.
First because I think issue handling on GitLab/GitHub kinda worsen the problem of the lack of maintainance resources, instead of fixing it
Second because we are quite strict on how to format changelog entries, and I believe email interactions help educating contributors in a nice way, while MR/PR interactions might generate more fatigue -- not so sure about this one, though.
The basic notion is that the email threads model is focused around the subject line, and PR-model is specifically designed to have discussions where the code changes take the main stage.
I'm sure if you ask Jonas Bernoulli, Steve Purcell, Oleh Krehel, Bozhidar Batsov, and many other prominent Emacs hackers, they'd probably agree, without PR-model, it would be a lot harder for them to find so many contributors for great Emacs packages they authored and maintain.
To be honest, it feels a bit ironic when the shepherds of Free Software (GNU hackers, et al.) choose to ignore the people's free will, and in 2020 it is clear - people have made their choice. They don't want to deal with email threads, patches, etc. The majority of developers prefer to be able to issue Pull-Requests instead.
But there's something else, there's now an entire generation of software developers who simply don't know how to deal with sending patches, etc., and they don't even care. And that's not a good trend. The issue of patches vs. pull-requests has become generational. And if the old software projects fail to adapt, I'm afraid they'd slowly start dying.
Agreed. I hope https://sr.ht can help resisting this trend. I'm sure there are plenty of happy Git(Lab/Hub) users here but again, I'm not convinced these platforms would fit Org's needs.
For me pull request model is much more natural than mailing lists and patches. It doesn't matter at all if its GitHub, GitLab or (my personal preference as it's lightweight, open source and easy to use) Gitea (interestingly it's not present in comparison on https://forgeperf.org). I don't even know how to make PR on sourcehut and can't find any tutorial.
Of course I will try to learn in order to help org but the entry barrier is much higher than for Git(Lab/Hub/ea).
EDIT: I just found orgmode code on Gogs here: https://code.orgmode.org/bzg/org-mode
That's great! I'll register and try to help soon! Mabye it should be more visible and linked in docs (I'll... make a PR I suppose? :)
Rather than attaching a patch, you simply send a link to your git repository (+branch if applicable), and the maintainer can pull from it.
But please clone Org's repo, make a patch - perhaps with https://magit.vc - and attach it to an email you send to emacs-orgmode@gnu.org: that's all it takes.
Then we will help with polishing your contribution :)
For those who are really taking advantage of org-agenda et al, I'd argue GitHub issue tracking UI is far more restrictive for tracking patches.
If I were in that position I'd be duplicating issues into org-mode anyway (or using an Emacs mode to interact with/sync them). Maybe that's the missing link?
(a) you have no ability to edit entries (or do anything else that email is bad at),
(b) the mail interface is frankly hard to read, with everything in uniform monospace font and no formatting,
(c) I can't participate or reply on the web interface, I have to sign up for something completely different to participate.,
and (d) because of the way the site is laid out, I can't see how to get the code, etc. from the bug tracker. I would presumably go back to Google and search for org mode and then try to figure it out from there. But that's just a lot more steps to do what could be made easy.
Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job.
I don't personally think that Github makes PR formatting any harder; I would expect any contributors to use a git command line to look at what they put in the commit message. But at any rate, that's some user education you'll have to do one way or the other. With the current approach, you've got a bunch of other barriers to entry that prevent you from seeing certain users in the first place.
Let me correct this one: no, you don't have to sign up to anything: (1) click on a bug entry on https://updates.orgmode.org then (2) click on "try the mailto: link" link.
This is other way around: if Org goes to GitLab, GitHub-only users will have to sign up to GitLab just to report an issue, and same for GitHub.
After all, it should be possible to have PRs sent as patches over a mailing list (and we don't need manual patches to be published as PRs.)
I also don't have "mailto:" hooked up to my actual email client, so that's extra steps for me to get that set up. (Blame me for this if you want to, but I'm guessing that there are probably more people like me in the world than there are people who have their email client set up to handle "mailto:" simply due to the fact that work is required to set it to anything other than the system default.)
The question is, what are you filtering for? There are always tradeoffs, and I hope I've demonstrated that the email-based interface is not "free" even for fairly savvy tech users. For less savvy tech users, I'd consider the situation even more difficult.
- Copy email eddress - M-x mu4e - S-C C-y C-c RET f <select patch exported with magit>
I found just sending an email with my contribution to be a much smoother experience than filing a pull-request.
Also M-x org-submit-bug-report
GitHub deliberately made GitHub-flavored Markdown incompatible with the way that Markdown dictated line breaks should be handled, although this affects more than just pull requests. In general, the way that people "write" Markdown meant to be published for GitHub is unreadable as plain text, even though it's supposed to be roughly as nice to read raw Markdown as it is to read the rendered form.
Many projects' commit logs are also a mess as a result of the way that GitHub pushed their pull-requests-for-everything model on the world. There is no end to the number of projects where every other log entry is a crufty merge commit, and the messages in those projects are generally useless, anyway. Folks shouldn't have to trawl through a disconnected web service to glean the info that should have been included in the commit message but was stuffed into the pull request instead.
> Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job.
I have no horse in any Emacs race, but I agree that proper bugtrackers trump mailing lists. It's just a shame that so many people have consolidated around GitHub (and workalikes, like GitLab and Gogs/Gitea), which is poorly implemented. GitHub implements less-than-optimal workflows for its own reasons, and those reasons generally mirror other Valley-based "social" endeavors, where what's most important is growth, user engagement, and the perception of value at the expense of actual productivity and the adoption of addictive dark patterns to drive it all.
Second to the actual mechanics of GitHub is "the GitHub community", which routinely proves to be as much of a liability as an asset.
The fact that Emacs is a free software project and GitHub is not and GitHub is only slightly less of a walled garden than Facebook and that its privacy controls (what little it provides, if you want to even try to argue that it provides any) are worse than what Facebook and Twitter provide...
... are all reasons that make for a very bad suggestion to move to GitHub.
- [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.]
- [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?]
- [For the copyright registration, what country are you a citizen of?]
- [What year were you born?]
- [Please write your email address here.]
- [Please write your postal address here.]
I have several bugfixes and enhancements to various org-babel languages that I maintain for my local code, but I have no interest in jumping through copyright assignment hoops or sharing my age & mailing address to push them upstream.
And in general people people in the current era of open source seem to be sloppier/more reckless than before. Ever looked behind the scenes of Wikipedia (or heck, just perused YouTube)? You know how much plagiarism and copyright infringement is involved? Enough to worry about it. (And in the case of media uploaded to Wikipedia, people have to specifically declare that the work is theirs to license or otherwise is free content, but even with those barriers, there are people still willing to do things that jeopardize the project.) Even if only half a dozen people were ever deterred (and the numbers are certainly higher than that), then that alone would be worth it.
Which is the better analogy than picking up trash, by the way.
[1]: https://www.theregister.com/2020/08/25/linux_kernel_email/
so while it might represent some trend, it is also worthwhile to possibly consider editorial/selection bias as a factor for promoting the claim that this is significantly prohibitive
What choice would all the scientists have in that case? They can't just say: "I'm leaving physics until someone else builds another LHC".
Until we have a better, more superior, free, open-source, public service that can do things better than GitHub, I'm afraid we'd have to play along.
But the point is not about GitHub vs. something else. It is about that Pull-Requests are preferred over mailing lists for open-source projects.
But you forget about Catholic Church dedication to Overall Truth that cannot contradict reality. Or you do not belive in it. I do. So, probably no point in discussing this, right ? ;)
In contrast to corporations dedication to them selves... Which just only on surface looks like cysnism on our part, sadly.
So, obviously MS takover over Github will end as soon as it will be convenient for MS.
But realy we have bigger problem on our hands: common ppl greed or just reluctance to pay (quite not much) for hosting of their own projects. Or paying anything for their privacy. This also is why FB already replaced home pages. And Discord (almoust overnight) TS.
We realy need to ad private git repos and own vpn's. For agents raiding servers locations should be enough.
https://news.ycombinator.com/item?id=24378401
There's also the matter of its privacy controls being extremely lacking. It's another site that takes the position that you don't get a choice on everything being "social" now, so they'll index your activity on a central timeline whether you ask for it or not and broadcast it to anyone else who does ask for it, leaving you with no recourse except to opt-out entirely.
For example, mrsh has its development on sr.ht[1], but accepts pull requests on Github or the mailing list for the project[2]. This seems like (almost) the best of both worlds to me, where people who want to use a mailing list can, and people who want to use a GUI can, though there is overhead for the maintainers to fuse together the results at the end. An alternative like Gitea or GitLab might be better for your mentioned privacy concerns while still lowering the barrier to entry that a mailing list workflow presents.
Design is not my passion, so I'm drastically underqualified to comment on whether any of these websites is an effective implementation of their ideas.
Another concrete example is eglot: it is developed in the open on GitHub, which is great. But it is closely related to two other emacs packages: flymake and eldoc, which are developed via emacs-devel, or something, I've never really understood. So when changes need to be made in those packages it suddenly becomes very opaque, and I am not at all sure how much code review goes on. (This is not at all a criticism of João Távora who maintains all three I think! It is more structural and related to Emacs development in general.)
It dissuades me from contributing to emacs in general. There is nothing advantageous about reviewing code by mailing list when we have GitHub and GitLab. For those of us who use GitHub and GitLab in our day jobs for code review and collaboration, it is really baffling and frustrating. Furthermore, although the org-mode mailing list is, I am sure, just as pleasant as it always way, lists like emacs-devel are incredibly toxic and depressing to read; a bunch of men arguing just like they did over IRC in the 80s and 90s. And good god, don't ever go near the #emacs IRC channel if you're not someone of that gender from that generation!
I am sorry to say it but the emacs community has an atmosphere problem: it is common for people to be unpleasant in public. For example, the magit maintainer responded rudely, aggressively, and discouragingly to recent PRs against magit. Stallman's absurd one- or two- sentence replies. This is of course not Org-mode's fault; but I believe the future of Emacs development is to embrace GitHub / GitLab like other open source projects and leave the crusty 90s-era practices behind.
I don't know if the tone of conversations is different on mailing lists vs. web UIs like issues, PRs or code reviews.
As I said in another reply, I guess we can somehow reconcile both worlds by allowing PRs to be sent as patches to a mailing list - I guess https://sr.ht could support something like this (if it does not already).
The thing with the whole "entry barrier" point of people who want Org-mode development to happen on Git(Lab|Hub) is that they miss the point: I don't want more contributions, I want more engaged contributors, more committed support of any kind.
I find emails to be more engaging than emojis on a web interface - and I use both on a daily basis, so perhaps I don't deserve my #okboomer yet :)
If you want more engaged contributors you need more occasional contributors. Some of them will grow into core contributors or co-maintainers. Putting more obstacles is not the way to filter the out less engaged and keep the committed one but way to discourage the potential valuable contributors. That is why being on github where practically all of the OSS is happening is important(even being is gitlab won't have the optimal effect).
I must reject that unfounded criticism. I looked at all PRs since May and the only one that I rejected without much of a justification is https://github.com/magit/magit/pull/4191. I have a hard time imagining how you justify going from that to your harsh choice of words.
Luckily feedback is overwhelmingly positive, but because I have a thin skin, harsh criticism still hurts me and at least temporarily makes me lose motivation.
> I am sorry to say it but the emacs community has an atmosphere problem: it is common for people to be unpleasant in public.
I don't think it is common, but it does happen.
From what I understand, Bram's vim development workflow is very similar to other emac's dev: submitting and discussing patches via the mailing list. There was something (a bot?) setup such that PRs are forwarded to the mailing list: https://github.com/vim/vim/blob/master/CONTRIBUTING.md
This was discussed pretty extensively when vim moved from Google Code to GitHub: https://groups.google.com/g/vim_dev/c/Io5A_Zir--k/m/faPCHWYf...
In general, PR/patches-friction should not be an obstacle for contributions because it can be alleviated in part by tooling that glues the workflows more-or-less seamlessly.
EDIT: It might be worth asking how the neovim community in general may have been helped by the decision to make github their home, or maybe even ask the emacs-lsp devs on their gitter: https://gitter.im/emacs-lsp/lsp-mode ?
EDIT 2: In the vim-dev mailing list, there are threads started from GitHub pull requests that include .patch and .diff files: https://groups.google.com/g/vim_dev/c/7VpUqzoQycY/m/W_7zhTGf...
I don't know if there's some way to "partially" move to GitHub—it would be cool if there were some service that synced GitHub issues with a different tracker, for example, but I've never seen that. Perhaps it would become too noisy.
Of course, more contributions might not be a net gain. For each dedicated contributor, you'll also get drive-by PRs and issues that add noise which maintainers have to deal with. I do not know how that trade-off plays out in practice.
So I can't give a definite conclusion about whether GitHub is worth it, but I would be willing to bet that working on GitHub would get you more contributors.