Seems relatively clear to me after reading the "Why" and "How" sections and liked issues. They don't mention Gitea/Forgejo specifically but I assume the idea is to use compatible semantics.
Fun, but as a GitLab user I’d much rather they address missing features of their core competency (code review), like the inability to “request changes” or otherwise block a merge (https://gitlab.com/gitlab-org/gitlab/-/issues/761, issue open 6 years), or adding the ability to both squash and merge AND use the merge train
I know companies are big organizations that can do more than one thing at a time, but we were just burned again recently by the inability to block a merge, and so I’m salty
Gitea and Forgejo have this functionality [0]. I've given up on GitLab ever implementing features that are directed at regular developers any more—they've pivoted to focusing exclusively on the enterprise purchaser rather than the day-to-day engineer.
I must be missing something...how is what you linked to relevant to the feature(s) that the parent is alluding to again? Surely you're not referring to Gitea WIP marking, which sounds functionally equivalent to GitLab Draft marking[1].
> If the maintainers request changes, you'll need to make those changes in your branch and push the changes to your forked repository. The PR will be updated automatically with the new changes.
Look at this PR for several examples of "requested changes":
You could probably do something similar with that, but it's not quite the same thing.
With that setting there's no native way to distinguish between threads that are intended to be blockers and threads that are just comments. They all must be closed regardless of intention before merging can happen, and because there's no way for the commenter to signal their intent that process is error prone. If anyone and everyone can resolve comments then you'll get merges that shouldn't have happened. If only the commenter can resolve comments then you introduced a ton of friction in cases where a comment was just a comment.
It's not that you can't accomplish the same workflows with GitLab's current features, it's just the GitLab doesn't help you the way the other forges do.
> With that setting there's no native way to distinguish between threads that are intended to be blockers and threads that are just comments. They all must be closed regardless of intention before merging can happen, and because there's no way for the commenter to signal their intent that process is error prone.
This may have merit if your default workflow mindset was all threads are non-blocking unless an explicit "request change" action is invoked.
GitLab's unresolved threads simply comes at it from the inverse perspective of all threads are blocking unless intent to move forward is explicitly conveyed by positively marking threads resolved. If the objective is to avoid unintended merges that manifest from inattentiveness and/or poor communication, then this is clearly the safer approach that preserves accountability.
In the case of just a comment, I see any friction created there as a direct result of poor communication between collaborators; if you can't unambiguously decide whether an in-thread comment is non-blocking/unactionable, then clarity of intent wasn't clearly conveyed to begin with.
Another thing that I thought was presumptive with this "requested changes" flag is that it signals that you want to see code change, but maybe your intent is to block a merge until the PR submitter is given an opportunity to more clearly defend an implementation decision, which may or may not result in a change.
Between draft marking, unresolved threads, and approval rules[1] to safeguard against unintended merges, I struggle to see how GitLab could possibly help me more.
There's a part of me that feels like differences in value perspective are driven by what's generally effective for open distributed collaborations v. the needs of closed enterprise teams.
Anyone, including the author, can resolve a thread in gitlab.
Say I, as a senior engineer, scan a junior’s MR and see a serious security issue. In GH I can request changes, and then re-verify prior to merge that the issue has been fixed correctly. With GL, the author, thinking they fixed it, can resolve the comment and merge.
...but if a junior incorrectly marks a thread resolved, then the senior gets traceability and an indirect feedback signal that tells you someone isn't naturally tracking and there may be room for communication improvement.
In any case, setting unresolved threads as blocking is just a safeguard layer. The scenario you describe is a routine encounter for me. Really sounds like the technical control you want is required approval(s)...of course, GitLab sales recognized that's what enterprise managers also highly value, so it's bucketed as a pay-to-play Premium/Ultimate feature.
Required approvals aren't the same thing either. With required approvals someone else can come along and approve a PR that I have previously asked for changes on. Yes, that does indicate something went wrong in the human process, but that's what tooling is for: moving things out of the human process and into a space where you can't break the rules if you tried.
> of course, GitLab sales recognized that's what enterprise managers also highly value, so it's bucketed as a pay-to-play Premium/Ultimate feature.
And this is my number one complaint with GitLab. There's no way to pay $4/mo for the basics. If you want required approvals you have to pay for their whole CI system even if your org is already using Jenkins, and for their issue tracker even if you're using Jira. They're all or nothing, and most organizations don't want all.
This is why I say that the only people they're trying to appeal to are enterprise purchasers who like the idea of paying for an all-in-one "solution", not frontline developers who recognize that bundling isn't always better and just want to have a decent system for managing their code reviews. GitLab isn't that: not only is their code review system still missing features that people rely on in GitHub, the ones it does have are gated behind a subscription whose cheapest pricing manages to be more expensive than GitHub's most expensive tier.
What's to stop another maintainer from actively dismissing[1] your requested change and merging anyways, and how is this scenario materially different than the same maintainer consciously disrespecting my unresolved thread while overriding my required approval?
Even more adversarial, why not just exploit the implied race condition of your process by having a new PR submitted for another maintainer to merge before you get a chance to block it?
If we're still in fact talking about a scenario involving a group of maintainers with equal authority over a protected branch, all I see is the inescapably human dilemma of collaborative communication and network of trust.
But if one "maintainer" has the asymmetric capacity to immutably block all others, then the goalposts have moved and we're not really talking about just maintainers with equal pull.
On an opinionated note, if there's anything I learned about embracing Microsoft, it's that you can't judge true TCO by merely comparing superficial sticker prices.
Call me skeptical, but whenever I look at any new proposed Gitlab feature I wonder: how will this help them convert more enterprise customers to their $100/seat Ultimate plan?
From the comments, Forgejo is also already working on implementing ForgeFed, an ActivityPub extension specifically designed for software forges [0]. Judging from the issue, it looks like they're well on their way [1].
I dislike even federated social media, but this is a use for federation I approve of wholeheartedly. The friction of having to create accounts on X forges (where X is the number of projects that self-host) is a huge moat for GitHub, and federation could solve that very handily and create an environment where FOSS projects can feasibly host their own code away from Microsoft's control without horribly inconveniencing everyone who wants to participate.
ForgeFed is the noblest attempt to decentralise git after GitHub made it popular.
It is potentially more DDoS resistant and secure, since your git web front-end (e.g. Forgejo) only needs to record ping-like messages, and you can react to them in your time, separate from public interfaces.
I just deleted a long comment asking why it said ActivityPub wasn't going to help with "implementing cross-instance forks" - so in case anyone is confused about the same thing: I believe they are saying, they will support cross-instance forks (that's the entire point, and why I was confused), but it won't be AP that's used to do this. AP will just be used for the comments etc.
For the local copy yeah but if you want the functionality of gitlab/hub to make a MR online from a fork then you need your own fork tracking the upstream which requires the two copies of the repos, hosted on each of the instances, to know about each other. Otherwise what is the point of having two instances, you would have a gerrit-like system where this is one server and you simply checkout a branch and then make a PR from the same repo.
(If you are asking, "is git clone enough to implement this" then...I think so? But the way the article was worded was confusing at first, like they didn't plan to support this at all.)
I imagine that creating a fork on your own instance, you just provide a url. UX-wise it isn’t as powerful as the one-click fork of a centralised platform, and I think we’d need a browser plug-in because of the missing implicit assumption of where to fork it.
oh yeah which link to use has been a nightmare of a UX problem with kbin/lemmy. Like, if someone links you a Lemmy page but you want to see it on your kbin instance, you need a link here, "open in kbin.social (or whichever instance)." But same for every link on the page?
I guess mastadon has better solutions for this, having existed much longer with federation, but it's definitely a downside. Maybe it's something that can be built into a browser in a more general way the way "email with" is for email links - a list of "these domains are actually federated" and "my options for opening them are" list, and you get links as needed, or popups. But there are additional issues when the post ids don't match on the different instances, so such a thing is not so simple as replacing the domain with %s in the right places.
31 comments
[ 2.6 ms ] story [ 86.8 ms ] threadWhat are you missing?
1. Allow interaction between GitLab instances (instead of users needing different GitLab creds for each instance)
2. Emerging "GitLab network" grows to compete with, then replace, corporate-controlled Git hosts.
I know companies are big organizations that can do more than one thing at a time, but we were just burned again recently by the inability to block a merge, and so I’m salty
[0] https://docs.gitea.com/next/usage/pull-request
I must be missing something...how is what you linked to relevant to the feature(s) that the parent is alluding to again? Surely you're not referring to Gitea WIP marking, which sounds functionally equivalent to GitLab Draft marking[1].
[1] https://docs.gitlab.com/ee/user/project/merge_requests/draft...
Look at this PR for several examples of "requested changes":
https://codeberg.org/forgejo/forgejo/pulls/764
[1] https://docs.gitlab.com/ee/user/project/merge_requests/index...
With that setting there's no native way to distinguish between threads that are intended to be blockers and threads that are just comments. They all must be closed regardless of intention before merging can happen, and because there's no way for the commenter to signal their intent that process is error prone. If anyone and everyone can resolve comments then you'll get merges that shouldn't have happened. If only the commenter can resolve comments then you introduced a ton of friction in cases where a comment was just a comment.
It's not that you can't accomplish the same workflows with GitLab's current features, it's just the GitLab doesn't help you the way the other forges do.
This may have merit if your default workflow mindset was all threads are non-blocking unless an explicit "request change" action is invoked.
GitLab's unresolved threads simply comes at it from the inverse perspective of all threads are blocking unless intent to move forward is explicitly conveyed by positively marking threads resolved. If the objective is to avoid unintended merges that manifest from inattentiveness and/or poor communication, then this is clearly the safer approach that preserves accountability.
In the case of just a comment, I see any friction created there as a direct result of poor communication between collaborators; if you can't unambiguously decide whether an in-thread comment is non-blocking/unactionable, then clarity of intent wasn't clearly conveyed to begin with.
Another thing that I thought was presumptive with this "requested changes" flag is that it signals that you want to see code change, but maybe your intent is to block a merge until the PR submitter is given an opportunity to more clearly defend an implementation decision, which may or may not result in a change.
Between draft marking, unresolved threads, and approval rules[1] to safeguard against unintended merges, I struggle to see how GitLab could possibly help me more.
There's a part of me that feels like differences in value perspective are driven by what's generally effective for open distributed collaborations v. the needs of closed enterprise teams.
[1] https://docs.gitlab.com/ee/user/project/merge_requests/appro...
Say I, as a senior engineer, scan a junior’s MR and see a serious security issue. In GH I can request changes, and then re-verify prior to merge that the issue has been fixed correctly. With GL, the author, thinking they fixed it, can resolve the comment and merge.
In any case, setting unresolved threads as blocking is just a safeguard layer. The scenario you describe is a routine encounter for me. Really sounds like the technical control you want is required approval(s)...of course, GitLab sales recognized that's what enterprise managers also highly value, so it's bucketed as a pay-to-play Premium/Ultimate feature.
> of course, GitLab sales recognized that's what enterprise managers also highly value, so it's bucketed as a pay-to-play Premium/Ultimate feature.
And this is my number one complaint with GitLab. There's no way to pay $4/mo for the basics. If you want required approvals you have to pay for their whole CI system even if your org is already using Jenkins, and for their issue tracker even if you're using Jira. They're all or nothing, and most organizations don't want all.
This is why I say that the only people they're trying to appeal to are enterprise purchasers who like the idea of paying for an all-in-one "solution", not frontline developers who recognize that bundling isn't always better and just want to have a decent system for managing their code reviews. GitLab isn't that: not only is their code review system still missing features that people rely on in GitHub, the ones it does have are gated behind a subscription whose cheapest pricing manages to be more expensive than GitHub's most expensive tier.
Even more adversarial, why not just exploit the implied race condition of your process by having a new PR submitted for another maintainer to merge before you get a chance to block it?
If we're still in fact talking about a scenario involving a group of maintainers with equal authority over a protected branch, all I see is the inescapably human dilemma of collaborative communication and network of trust.
But if one "maintainer" has the asymmetric capacity to immutably block all others, then the goalposts have moved and we're not really talking about just maintainers with equal pull.
On an opinionated note, if there's anything I learned about embracing Microsoft, it's that you can't judge true TCO by merely comparing superficial sticker prices.
[1] https://docs.github.com/en/pull-requests/collaborating-with-...
I dislike even federated social media, but this is a use for federation I approve of wholeheartedly. The friction of having to create accounts on X forges (where X is the number of projects that self-host) is a huge moat for GitHub, and federation could solve that very handily and create an environment where FOSS projects can feasibly host their own code away from Microsoft's control without horribly inconveniencing everyone who wants to participate.
[0] https://forgefed.org/
[1] https://codeberg.org/forgejo/forgejo/issues/59
It is potentially more DDoS resistant and secure, since your git web front-end (e.g. Forgejo) only needs to record ping-like messages, and you can react to them in your time, separate from public interfaces.
(If you are asking, "is git clone enough to implement this" then...I think so? But the way the article was worded was confusing at first, like they didn't plan to support this at all.)
I guess mastadon has better solutions for this, having existed much longer with federation, but it's definitely a downside. Maybe it's something that can be built into a browser in a more general way the way "email with" is for email links - a list of "these domains are actually federated" and "my options for opening them are" list, and you get links as needed, or popups. But there are additional issues when the post ids don't match on the different instances, so such a thing is not so simple as replacing the domain with %s in the right places.