It is acceptable to use proprietary tools to promote and work on free software when no comparable tools exist and when you're working on replacing those proprietary tools. GNU was originally built using Unix after all.
[0]β and sometimes not so gently when I think they should know better: https://libranet.de/display/0b6b25a8-1260-5ac6-ac61-146110080267
Github was proprietary from the beginning, but after Microsoft's acquisition it has moved deeper into the Extend phase with Github CLI. They're aiming for the entire open source infrastructure to orbit around them. Don't help them move the free software and open source world in this direction. You don't actually need Github. They need you.
Please consider Gitlab Pages, which at least publishes a highly capable open source edition of its product, before considering Github Pages.
@clacke Or be an unfrozen caveman, grab the cheapest VPS/d.o droplet
files go in /var/www
sudo apachectl start
Time for beer.
Gitlab CI existed before Github Actions, it's not Gitlab that is playing catch-up.
@clacke @codeberg Gitea is ok, and at least is a reasonable solution to self host and is all free software.
It still suffers from the malady of building a big web framework around the limitations of git itself, and it's very heavily online (as opposed to distributed) in a way identical to GitHub.
I do wish more people would look at Fossil and either use it or copy its model.
I do wish more people would look at Fossil and either use it or copy its model.
Fossil is very cool in a lot of ways. Having the entire web interface, wiki, etc. bundled into a single executable is awesome.
But I donβt think itβs a suitable alternative for git for most projects, because of the fundamentally different contribution model that they work under: the whole cathedral (fossil) vs. bazaar (git) model.
https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#vs-linux
@clacke Gitea is basically github but Open Source, they haven't done anything else. Contribution model is inefficient and creates vendor lock-in.
For most people who want to manage source code projects and community contributions, the centralized web host is unfortunately the most usable and familiar model we've come up with so far.
@clacke The problem is that contributors should make an account on the server where the project lives, then fork it and make a pull request. It's a lot of waste and unintended side effects like creating a new account
The remaining problem is that you need an always-on, publically-addressable intermediary at all instead of just running a P2P node locally.
So far I haven't found a distributed issue tracker I can unreservedly recommend people to use. But they have become a bit better lately than they were 9 years ago.
> That is exactly the friction that ForgeFed addresses
Email does too, https://git-send-email.io
i setup my own instance, check in my code, do all the stuff with issues, ci and so on...
another one also setup his own instance... but he can fork a repo from my instance, comment on my instance, make PR to my instance and gets updates from my instance - and the other way round.
git itself is build on this model only with the repo itself... but all the web-stuff around should federate also.
if it federates with activitypub, we can follow an issue or repo also here on mastodon/pleroma too... to get news about a trendy repo...
i have also my own nodes for my fediverse-services... but look at matrix. i think i've read, that over 90% of all matrix-accounts are registered on matrix.org.
there is also a concentration on mastodon...
and if some people work together in a project, they will have their fed-git-accounts also on the same host... i believe. So the big load of forks and PR in daily work will happen locally.
@jakob @clacke Ok, even if this thing would be implemented and standardized, it would take ages before good tools are available and this gets at least some adoption.
Email is already a thing, there are a lot of useful tools to work with it (git send-email, good clients) and it's used by PostgreSQL, Git, Linux kernel and a lot of other projects. There are hosted services which make the process easier for individuals: https://sourcehut.org. Do we really need anything else?
but to make a pr, i have to fork the project first, which is a clone to my host... i have to do it anyway...
ok. on github/gitlab i do the fork on the same host. no network-bandwidth is necessary.
but if i want to edit this repo on my local machine i have to clone it to my laptop...
in a federated git, from which i'm dreaming, the initial fork with the big amount of data-transfer is not local... yes. i know. this is over network and needs a lot of bandwith...
AFTER this initial fork, almost only the changes are transferred... also on a pr...
isn't it?
we have some jira instances at work, and some of them have to communicate with jiras from other companies... and some of these connections work over email. and sometimes, they do not work. why?
because email is NOT good for this purpose any more. spam-filter, blacklistings... and so on do not guarantee, that the update-email is delivered... why should this work better with git?
we try to move all this connections from email to native REST-connections. So we can give the guarantee, the update comes just in time and it will come!
And if something is new... yes, it takes it's time to be established. Even if it is good...
Maybe it's enough to add ActivityPub-functionality to Gitea or Gitlab... Or someone found a totally new concept for webbased git solutions based on activitypub - which is also relatively new defined as web-standard for federation from the W3C...
on github (which i used most in the past), i have to fork a project. then i clone the repo to my local computer, do my work, create branches, patches and so on. pull it to *my* repo on github and create a pull-request to the original project, where i've forked it before.
what i understand from that:
forking a repo on github means making a copy of the full project from one users directory to my users directory. i need bandwidth for that. because the whole project has to be copied.
this is, what have to be done over network from one fed-git instance to another fed-git instance. and THIS happens only one time in lifetime of the fork.
right?
all other actions only transfer patches, diffs, updates from one instance to the other in a federating git system... or from one repo to the other on gitlab/github/gitea nowadays.
right?
@jakob @clacke nevermind then I guess. But still, AP in my opinion is not really suitable for software development, it's better for what it's used for - social networking. We need either (1) a new protocol that solves all problems, (2) use email or (3) continue developing proprietary (non-standard) protocols for new walled gardens. Email is not that bad as you might think, if you exclude gmail from the equation, everything is pretty good.
your role is to show the drawbacks... that is a very important role.
but i think, it's not time to talk about protocoll-details, because the big thing does not exist now... and i'm sure, out there in the world are developers, which can find ideas how to realise an activitypub based federated web-git solution... i'm sure, this developers are existing.
it always need guys with ideas, guys with skills to realise such an idea and guys wich will show the problems.
i personally do not have the skills to develop such a thing... my hope is, to reach a developer with my idea, who is also fascinated about this idea, picks it up and makes it... and if not... we have good working tools now. it's also ok.
- replies
- 0
- announces
- 0
- likes
- 1
it is not trustable, that updates sent by email are really reach the target...
maybe activitypub is not the best protocoll for git... maybe it is... but no one tried it till now. What i can send through email, i think, i can send also by activitypub. not?
@jakob @clacke Don't assume if exchange is unstable, everything is. I've been using sourcehut for 4-5 months and haven't had any problems with emails not arriving or anything like that (given that I used gmail and switched to a different provider only ~2 months ago).
And no, activitypub is not an email killer. There are no tools to easily work with AP besides web UIs (which is awful given that email has a ton of CLI clients and fancy stuff like git send-email)
but we live in a windows-world... and it's not my decission...
and i didn't say, activitypub is an emailkiller... i said, what you do with email in git, you can do also with activitypub. and a lack of tools now doesn't mean a lack of tools in future...
@yyp @clacke and itβs not a question about an unsable exchangeβ¦ itβs a question of spam/junk-filter updatesβ¦ many people send documents over emailβ¦ yes, that is not idealβ¦ that is very badβ¦ but people do this since 30 yearsβ¦ so why should thy change their behaviour, if there is no need for that? if they are not forced by shrinking the attachment-sizeβ¦ and so there are permanently adjusted junk-filters which make email bad for updates and system-notifications.
What i understood from activitypub is, you send a json-message to a rest-endpoint (inbox) or put such a json-message to a outbox, where it can be crawled.
whats that difficult, if you have a fed-git based on activity-pub, and a git module, which can put a json to the fed-git inbox, similar a git remote pushβ¦
the question is, what kind of message should it be? whatβs the content. only a notification, that the other git can pull from my git? Or the patch itselfβ¦ soβ¦ guys who know git and activitypub better than me CAN think about this and find a solution, if they want.
It's the former, just a notification.
> guys who know git and activitypub better than me CAN think about this and find a solution, if they want.
They did. π
https://forgefed.peers.community/vocabulary.html#act-push
You can run an AP server on a Raspberry Pi and follow 1000 people posting 25 posts a day without a hitch. Your bandwidth can handle following a couple of dozen git repos over ForgeFed.