5 ms·

> Gitea and Forgejo have this functionality [0]. I must be missing something...how is what you linked to relevant to the feature(s) that the parent is alluding

> Gitea and Forgejo have this functionality [0]. 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/drafts.html https://docs.gitlab.com/ee/user/project/merge_requests/draft...

deleted 3y ago
[deleted]
lolinder 3y ago
> 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": https://codeberg.org/forgejo/forgejo/pulls/764 https://codeberg.org/forgejo/forgejo/pulls/764
- metaphor 3y ago
  Thanks for clarifying. That just looks like the functional equivalent of setting GitLab unresolved MR threads as blocking[1] though. [1] https://docs.gitlab.com/ee/user/project/merge_requests/index.html#prevent-merge-unless-all-threads-are-resolved https://docs.gitlab.com/ee/user/project/merge_requests/index...
  - lolinder 3y ago
    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.
    - metaphor 3y ago
      > 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. [1] https://docs.gitlab.com/ee/user/project/merge_requests/approvals/ https://docs.gitlab.com/ee/user/project/merge_requests/appro...
      - mplanchard 3y ago
        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.
        metaphor 3y ago

deleted 3y ago

[deleted]

lolinder 3y ago

> 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": https://codeberg.org/forgejo/forgejo/pulls/764 https://codeberg.org/forgejo/forgejo/pulls/764

metaphor 3y ago
Thanks for clarifying. That just looks like the functional equivalent of setting GitLab unresolved MR threads as blocking[1] though. [1] https://docs.gitlab.com/ee/user/project/merge_requests/index.html#prevent-merge-unless-all-threads-are-resolved https://docs.gitlab.com/ee/user/project/merge_requests/index...
- lolinder 3y ago
  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.
  - metaphor 3y ago
    > 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. [1] https://docs.gitlab.com/ee/user/project/merge_requests/approvals/ https://docs.gitlab.com/ee/user/project/merge_requests/appro...
    - mplanchard 3y ago
      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.
      - metaphor 3y ago