I have had my eye on these technologies for a while. Embedding the issue tracker and such in your git repo. Every day these make more and more sense.
I have had my eye on these technologies for a while. Embedding the issue tracker and such in your git repo. Every day these make more and more sense.
I made the decision to leave Github a couple months ago when I retired and started heavily working on personal projects. I like the idea of radicle and used it for a while, but it's complicated to set up and maintain if you want to run your own seed node and pin your personal projects.
What I ended up with is a version of a static forge - Charm's soft-serve to host the repos and a forked version of the pico.sh pgit static site generator. I added git-bug integration to track issues in the repo and an alternative CLI to git-bug that works better when collaborating with agents.
A static forge site is very resilient to bot traffic because it only renders a limited number of commits, instead of pathologically allowing a near infinite number of URLs for bots to crawl.
https://kilimanjaro.io if you want to see what it looks like.
I would agree with everything you say, but why not both?
We are actually facing 2 distinct problems:
- Github is a centralized, controlled git hosting, identity, collaboration platform.
- Bots are attacking any public facing interface.
So maybe the solution is:
- to keep a Radicle node private/behind fences to lower the maintenance/security burden, with eventually access to selected collaborators.
- publish the repos with a static site generator like pgit
Indeed really quick and responsive
Exactly this. Even though I don't use git-bug anymore, I'm still a sponsor. I desperately want an issue-tracker-in-.git to become a standard.
Issues and CI are the only lock-in. The latter is legitimate because you're using someone else's CPU, but every developer has the tooling to "git diff" and write comments if we could just agree on a format.
I have trouble wrapping my head around how to make it so the public can create an issue in your git repo.
They can clone the repo, make changes, and then push. On the server, you can have a hook that checks if the commit only contains appropriate issue changes, and apply just those.
Sure, a little more complicated than “Create Issue”, but not that much for devs. We could even simplify the workflow with e.g. git-issue or something like that, similar to e.g. git-send-email.