2010: Let's make GitHub the new SourceForge!
-
@bortzmeyer
I remember a story about some Forge, jo, and they wanted to federate.
Even GitLab reopened their ActivityPub issue, but progress is slow and the actual need for ForgeFed-edarion seems to be not so pressing, after all?
@rysiek@yala
I wanted to contribute to #garage S3 and they self host a forgejoe. It was a bit annoying having to create an account. It probably cost me two days before I opened an issue and my PR. It is just friction we need to solve.
@bortzmeyer @rysiekWrt codeberg and forgejoe, I'm wondering how actual development and independent feature contributions are compared to gitea.
-
@bortzmeyer git over email is so underrated...
And yet, it is federated by design, and sometimes even more efficient than some forges...
@yala @rysiek@x_cli @bortzmeyer @yala @rysiek : and it works offline !
-
@bortzmeyer git over email is so underrated...
And yet, it is federated by design, and sometimes even more efficient than some forges...
@yala @rysiekI disagree on one point : I am unable to manage git branches with git-sendmail.
-
I disagree on one point : I am unable to manage git branches with git-sendmail.
@tanavit Could you please explain in more details what you mean by "managing git branches"?
-
@x_cli @bortzmeyer @yala @rysiek : and it works offline !
@ploum @x_cli @bortzmeyer @yala @rysiek And then you try to plug automation to it... And the entire thing falls apart.
This is why most freedesktop.org projects switched away from emails. Patchwork-fdo tried super to provide a consistent view of patch series to review + associated CI results, but emails are too unstructured to work reliably (not including the fact that many email providers tamper with patches).
But worse than this, there cannot be collaboration on a shared global state for the project: no shared list of open issues, no integrated CI,... People just have to read the every email and build a mental image of the whole project. This doesn't scale, and Linux proves it...
I am all for decentralisation and offline operations, but basing it on emails just doesn't work. When all you have is a hammer, everything looks like a nail I guess...
Signed, a Freedesktop.org admin who has been spending 5 years on bringing the i915 driver quality up (https://intel-gfx-ci.01.org/, https://patchwork.freedesktop.org/), then 5 years doing the same in userspace using gitlab. The former is a joke compared to Mesa CI.
-
@tanavit Could you please explain in more details what you mean by "managing git branches"?
Suppose the main manager of a git repository proposes two branches (e.g. main and dev).
If I worked on the dev branch, the patch I will send does not have information about the branch I was working on, nor information about the official commit it applies to.I may be wrong.
-
@bortzmeyer @yala @rysiek Worse than having to create an account on some random GitLab instance is being asked to do it again because the one you had was deleted for not being used often enough.
-
Suppose the main manager of a git repository proposes two branches (e.g. main and dev).
If I worked on the dev branch, the patch I will send does not have information about the branch I was working on, nor information about the official commit it applies to.I may be wrong.
@tanavit It could be easily added to the cover letter, but AFAIK, you are correct that a "patch" (format-patch) won't contain that info by default.
git-request-pull is probably more suited for this? -
@tanavit It could be easily added to the cover letter, but AFAIK, you are correct that a "patch" (format-patch) won't contain that info by default.
git-request-pull is probably more suited for this?I agree.
-
@bortzmeyer
I know of two projects working on a federated git repos solution, one of them is @radicle.
Not tested though.
@yala @rysiek -
R relay@relay.infosec.exchange shared this topic
