The curl project’s source code has been hosted on GitHub since March 2010. I wrote a blog post in 2013 about what I missed from the service back then and while it has improved significantly since then, there are still features I miss and flaws I think can be fixed.
For this reason, I’ve created and now maintain a dedicated git repository with feedback “items” that I think could enhance GitHub when used by a project like curl:
bagder.github.io/github-feedback
Useful feedback
The purpose of this repository is to allow each entry to be on-point and good feedback to GitHub. I do not expect GitHub to implement any of them, but the better we can present the case for every issue, the more likely I think it is that we can gain supporters for them.
What makes curl “special”
I don’t think curl is a unique project in the way we run and host it. But there are a few characteristics that maybe make it stand out a little from many other projects hosted on GitHub:
- curl is written in C. It means it cannot be part of the “dependency” and related security checks etc that GitHub provides
- we are git users but we are not GitHub exclusive: we allow participation in and contributions to the project without a GitHub presence
- we are an old-style project where discussions, planning and arguments about project details are held on mailing lists (outside of GitHub)
- we have strict ideas about how git commits should be done and how the messages should look like etc, so we cannot accept merges done with the buttons on the GitHub site
You can help
Feel free to help me polish the proposals, or even submit new ones, but I think they need to be focused and I will only accept issues there that I agree with.
Submit issues, pull-requests or bring up a discussion.
Daniel,
I think the points you mentioned above do not make curl any “special” project, your requirements are normal for a long-maintained project that focuses on quality and maintainability first, and I think there are many such projects around. It’s just that they are marginalized in a world where the number of commits, contributors or stars is the essential metric, and where clicking to lazily merge random code without fixing trivial style issue is the optimal way to pursue that quest.
But some long-standing projects like curl, linux, git, gcc, haproxy, mutt, postfix, coreutils, apache, glibc, nginx, postgresql, freebsd etc unsurprisingly continue to exist and be actively developed outside of github using the good old proven and efficient process, and use github to help interact with more users though the workflow on this side is far from being the smoothest one! In this case it’s not as much the projects’ fault as it is the poor suitability of tools and interface (e.g. disable PRs, ease retrieval of plain text patch to manually apply it, or automatic forward to mailing list for discussion, etc).
There are convenient tools provided by github, like CI or issues, but they try to force us by social pressure to use all of it while it’s not all suited. It’s clear that a bit more flexibility would be great.
This sounds to me why we should not use proprietary platform for free software development.
umx: yes, a FOSS solution is of course always preferable, but it’s not actually as if there is any free one provided anywhere that has all these features anyway, and while a FOSS solution in theory would allow me to work on such features myself, limited time and my limited knowledge of the used technologies would then just end up me writing the same kind of wishlist for those platforms…
If you haven’t evaluated it yet, you could always have a look at hosting the project on https://sourcehut.org/. Without knowing more about your needs, mailing lists and email-driven workflow for instance are first-class citizens there, which seems to align with at least some of the curl project’s needs. And the founder being Drew DeVault, Sourcehut will always be true FOSS.
Simon: thanks, but I’m not planning to relocate.