Publishing is done using Github’s pull-request mechanism, which allows automated checks to be run, and discussion to happen with the maintainers before your contribution is merged. You will need a Github account.
– opam - Packaging
Is there another way that doesn’t require a GitHub account?
You’ll have to mail it to one of the opam repository maintainers with a Signed-off-by line (so we know who to contact in the future regarding the commit) and request them to create a PR on your behalf so that the CI scripts can run. It’s difficult to tell if that’s acceptable or not to you as you don’t say why you do not want to use GitHub.
I used to have an account there but I was concerned about the dominance GitHub started having, such as projects forming contribution flows with strict reliance on GitHub; I wrote about it here. The purchase by Microsoft added further to my concerns, particularly privacy.
Your mail based suggestion works for me. Can you privately message an address I can use? The packages I’m planning to start publishing are here.
Understanding the importance of a web interface to many, I wish we at least had our own Gitea or Gitlab service. I can help with either if ocaml.org admins are up for it.
Not having a github account won’t particularly help reducing their dominance (it doesn’t prevent others from hosting their projects there), and won’t help your privacy (you need not remain logged in, and they can’t violate your privacy unless you give them interesting information. It’s not an effective protest either.)
I recommend that you instead keep your github account, not use it very much (only for purposes like requesting pulls on other people’s projects), host your own projects elsewhere, and contribute to open source alternatives to github as your way of trying to prevent platform dominance, instead of just avoiding having an account altogether which won’t be particularly effective.
Thank you for your recommendation, but I have reasons to disagree with your statements:
It does help reducing their dominance: one less person; I had to learn and setup alternatives. I’m also voicing and demonstrating the alternatives. Going with the flow on the other hand would almost certainly not have helped.
It does help my privacy: because it reduces their data-points on me (e.g. they don’t have my account details; have to use alternatives), which will probably become Microsoft data to correlate with other data they have (remember they have LinkedIn? and browser signatures are good enough identifiers).
I respect the practicality of your recommendation, but I believe the course I have taken is better, it certainly makes me feel so. It’s also about escaping the web-page work flow .
@anon72795300 I think that if you stick to use your github account for only publishing to the opam repo it won’t invalidate your two points (and IIRC the only thing you need to provide to them is an email address). Besides if you use opam-publish you will see little of the web-page workflow, except for the discussion that may ensue if your contribution fails the various automated checks that are performed to ensure the health of the repo.
One thing to remember is that managing the contributions to the opam-repository is a rather time-consuming and unglamorous task managed by volunteers and I think we should rather ease their life than make it more complicated. With that respect I’m not sure that starting to email them package contributions goes in that direction.
I think that a lot of people share your concerns (myself I always treated github as a mere mirror of my repos, except for the issue tracker) but I guess there’s quite a bit of infrastructure that would needs to be setup (and maintained) to be able to match the current service and necessary user interactions.
Human power and ressources for these tasks remain limited.
My aim is not to make the maintainers’ life more complicated, although what I’m asking for inadvertently does and I have offered my time toward what I’m proposing.
I have deleted my account many months ago. Ultimately this is not just for me, but for others too. Contributing should not depend on a single company and compelling community members to join them. I think we all know that is not technically required and we can do better than this.
Thanks for explaining your motivations @anon72795300, and for kickstarting this discussion. In the longer term, I definitely want to reduce the coupling on GitHub, but of course it’s just difficult to know where the short-term projects to start this off are.
There are a couple of efforts underway already to make this possible. The OCaml CI is based on Datakit, which has an API bridge to GitHub that mirrors PRs into a local filesystem controlled by Irmin (a Git library in OCaml). This in turn has a bidirectional bridge which writes back to GitHub, but could also serve the results directly (as https://ci.ocamllabs.io does for opam-repository submissions).
We’re also working hard on a usable email implementation that works on real-world contents. One idea for an immediate next step would be to construct an email->Irmin bridge that would receive git patchbombs and convert them into GitHub PRs via a bot account. That should satisfy your (reasonable) request to not have to have a GitHub account to contribute to opam, and also let us maintain the existing workflow. Is this something you’d be willing to contribute to?
Note that, without a longer term plan, I am resistant to just kicking off an official ocaml.org GitLab instance. It’s a lot of work to maintain, and simply splits our already stretched infrastructure maintenance efforts. However, I am very open to such a longer term plan being written to motivate the move. I already operate https://gitlab.com/ocaml-platform for some CI runner tasks, and am in the process of requesting access to gitlab.com/ocaml for more official use.
I’d be very interested to participate in anything OCaml-email and Irmin is something I’ve been considering for Logarion.
If you don’t might me taking some time to catch up, then I’d gladly contribute. Let me know what to do next (hopefully not make a GitHub account :P).
Hope you gain access to gitlab.com/ocaml. I maybe be able to help there too if you wish; have maintained a in-house Gitlab instance for some years, but now-days I think Gitea is much nicer.
While other projects (namely Rust) have demonstrated that it is possible to maintain a large-scale open-source project on GitHub, it was far from clear that GHC could pull this off with our comparatively limited resources and significantly larger legacy migration needs (e.g. we concluded early on that any migration must faithfully preserve GHC’s ticket history, including ticket numbers).
From the recent thread on the caml-list regarding migration from the Mantis bug tracker to GitHub issues:
Hello,
On Mon, Mar 11, 2019 at 12:07 PM SP wrote:
Is it possible to use a different platform, not Github?
Given our limited resources and that OCaml itself is already hosted on
GitHub, it didn’t make much sense to consider something else.
Sorry!
Best wishes,
Nicolás
I guess the two projects had different constraints and available resources.
And I already replied above about our efforts in a self-hosting direction via GitHub bridges, that are already deployed and live for several years now. Just saying – it’s very hard to effect large-scale change if you’re unwilling to use the existing tools in order to build the next ones. Is there some element of GHC’s migration strategy that you consider relevant to OCaml, that could help?
Is there some element of GHC’s migration strategy that you consider relevant to OCaml, that could help?
Not really, other than opening up to the possibility and starting something parallel, however slowly it happens. Leaving this alone will unlikely make this better.
Again this a humorous nudge, I appreciate this is great effort.
I am in this de facto state currently. I started using code.rhodecode.com , framagit, and gitlab.com in recent years. I haven’t formed my opinion on rhodecode yet.
I settled on gitea through codeberg. The import from github is nice as well. Reddit threads also recommend notabug (gogs). Rhodecode was okay, slower roadmap. Gitea might sustain momentum, it’s good already. It doesn’t appear to be run by one company, like gitlab and rhodecode are run.
Meanwhile other parts of our world are not enjoying our “free” software:
On 3rd Oct. 2020 GitLab blocked Iranians’ access (based on IP) without any prior notice!
GitLab is not the only actor in this discrimination against Persian/Iranian people, we also blocked by GitHub, Docker, NPM, Google Developer, Android, AWS, Go, Kubernetes and etc.