Monitoring forge features and its impact on forge federation #120
Labels
No labels
User Research - Accessibility
User Research - bug
User Research - Config (instance)
User Research - Dashboard
User Research - documentation
User Research - Errors
User Research - feature
User Research - federation
User Research - Filters
User Research - governance
User Research - Labels
User Research - Moderation
User Research - Needs Input
User Research - Notifications
User Research - release
User Research - Repo creation
User Research - Repo Units
User Research - security
User Research - Settings (in-app)
User Research - testing
User Research - UI
User Research - UX
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Reference: forgejo/discussions#120
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@natct and myself will start monitoring forge features in the context of the F3 project. Our goal is to figure out how to represent those features for data portability purposes.
I also think it matters for the long term strategy of Forgejo.
Forgejo is an underdog compared to GitLab and GitHub as they ship an order of magnitude more features (see GitHub roadmap and GitLab release announcements). But Forgejo does not try to compete on that level. Instead it focuses on implementing Forge federation which will eventually make centralized forges such as GitHub a thing of the past.
However, forge federation can happen effectively if the features that matter to a given forge user can be communicated to another forge. Either via a Forgefed message or via a F3 archive. And, as can be expected, proprietary forges such as GitHub will do their utmost to lock users in by making them addicted to new features that cannot be found elsewhere. The latest of which being copilot, but it is not an isolated example.
Here are two feature examples and how they relate to federation:
In other words, when a new feature is released, its impact on forge federation can be evaluated and the strategy modified accordingly, if needed.
@jerger @pere @earl-warren @oelmekki since you are actively involved in forge federation (not necessarily in Forgejo), do you think this monitoring of forge features is a useful thing to have?
Monitoring or at least listing forge features is a valuable work anyhow, I think.
If monitoring features mean, we should collect requirements before designing lets say "federated fork" or "federated PR" this might be wise :-).
If there are flows like agit flow, git flow, trunk-based-development and more (see https://www.gitkraken.com/blog/trunk-based-development#git-branching-strategies) we should collect them and ensure they will also work in case of federation.
Are there other forges that you know of than Forgejo and GitLab working on this currently? I didn't get if the reference implementation on the ForgeFed site is a demo or something actually used in production.
Maybe at some point we'll need a forum similar to the one from activiypub.rocks (or even use their one in a community dedicated to ForgeFed) if we want to keep other projects posted and not requiring them to keep track of all others, or if we want to discuss all in the same place.
Edit: actually, I see there is such category already. Maybe we should start posting there. 😅
Two of them at a very early stage of development:
At this stage neither of them is production ready.
It is valuable for Forgejo to keep an eye on the features added to other forges, precisely because it is an underdog. There is no way it can compete, this is a given. And it would be tempting to turn a blind eye because of that and pretend the problem does not exist. But it does and needs to be dealt with, integrated in the federation strategy so that it is not defeated.
I took a look at the GitHub features from Q4 2023 and this is what I get:
I'm not exactly sure what to do with that, except for the import / export aspect which has a clear relationship to federation. But that alone is worth the effort of monitoring the roadmap at least for a few months.
@oelmekki since you're quite familiar with GitLab, is this URL the best one to figure out, from a distance, what new features are added to Gitlab? Or is there another one which would be more convenient for that purpose?
Regarding GitHub, the GitHub Enterprise release notes is what's worth monitoring rather than the GitHub.com online service. There is a lot more going on there.
@earl-warren Just to not be misleading, I wouldn't call myself a GitLab expert (I've used it intensively by self-hosting it for a few years in its early days, but then moved to just using bare git repos and git hooks for deployment, only getting back to it last year when I decided to move my FOSS projects from GitHub to gitlab.com). What I do personally to follow their news is to read the RSS feed of their blog. Their posts are written by dedicated writers who often explain the features well better than a changelog entry (an example). Of course, it does not contains everything, but following everything would probably be difficult, given the amount of commits made all day long by employees.
If you want an exhaustive list nevertheless, I'd think the best is to follow the changes on the the CHANGELOG file (with its archives). When we do any significant change, we're supposed to tag our commit message so that it's picked by an automated task that updates this file, so it's a good source of truth. The only thing more exhaustive is the commit list, of course.
Wikipedia would be a nice place for such an overview. What do you think?
It may be problematic for them. They have a policy against writing content that is not referenced in an other source, and I often see changes reverted because they use a source, but a primary one instead of a secondary one (eg, citing a press release rather than an article from a journalist reporting it). Writing about yourself or your organization is also usually frown upon.
Messages from an account created to circumvent a ban from Forgejo spaces were deleted, please get in touch with the moderation team for more information.
Today @natct and myself bootstrapped a timeline of GitLab features and went through all the features from the GitLab 16.9 release. Here are those that are Free Software.
On that occasion I discovered the existence of GitLab direct transfer which is relevant to F3 and how Forgejo & GitLab could communicate. This is for me a confirmation that this audit of GitLab release notes is worth the effort. I am less interested in features such as the Rich text editor that was introduced last year in GitLab and is now being used in more places. Maybe the same UI components could be used in Forgejo as well?
auto_cancel:on_new_commitwill be canceled when the commit associated with them changes. If marked asinterruptible: trueit will also have an impact on jobs currently in the pending state.I think F3 covers what "direct transfer" in GitLab is about. In the context of GitLab there is this recommendation regarding users: https://docs.gitlab.com/ee/user/group/import/#prepare-user-accounts
This may be fine for a one time migration but it could be automated. The Forgejo driver for F3 can create users if given admin access: the person doing the import needs to verify such accounts are not malicious but does not need to do the work themselves.
The migrated project items is the equivalent of the checklist of the F3 driver for Forgejo and has many more items.
Interesting read.
Today @natct and myself bootstrapped a timeline of GitHub features and went through the features from the GitHub Enterprise 3.12 release.
On that occasion I discovered the existence of GitLab Actions deployments which is relevant to Forgejo. My impression is that it is an unnecessary bloat. It could be implemented without being something special in GitHub Actions. But it is tightly integrated and documented because it makes it easy to deploy on Azure. It claims to be for all third party hosting service providers, but the repository containing starters workflows mainly has Azure, and a handful of others.
There is an improvement related to merge queues which is a features that would be very useful to Forgejo, but it is non trivial to implement. Maybe the mergify implementation could be a source of inspiration, even though it is tightly bound to GitHub.
dev_T referenced this issue2024-06-09 01:02:02 +00:00