Support ActivityPub for merge requests

Post by RheingoldRiver » Mon, Aug 28, 2023, 1:58 AM UTC

sshine wrote: post #30

RheingoldRiver wrote: post #23

Earlier quoted context omitted.

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…

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.

Post by metaphor » Mon, Aug 28, 2023, 2:45 AM UTC

lolinder wrote: post #28

metaphor wrote: post #27

Earlier quoted context omitted.

...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…

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 enterpr…

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.

[1] https://docs.github.com/en/pull-requests/collaborating-with-...

Re: Support ActivityPub for merge requests

Re: Support ActivityPub for merge requests