Unify/Connect issue/mr discussions across copies
Issue idea came from: http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html
Usecase
I included a part of the linux kernel git workflow below, but as it talks about more than just this problem I wrapped it in <details></details> tags.
Pull Requests
Pull request need to be attached to multiple repos at the same time, while keeping one unified discussion stream. You can already reassign a pull request to a different branch of repo, but not at multiple repositories at the same time. Reassigning pull requests is really important, since new contributors will just create pull requests against what they think is the main repo. Bots can then shuffle those around to all the repos listed in e.g. a MAINTAINERS file for a given set of files and changes a pull request contains. When I chatted with githubbers I originally suggested they’d implement this directly. But I think as long as it’s all scriptable that’s better left to individual projects, since there’s no real standard.
There’s a pretty funky UI challenge here since the patch list might be different depending upon the branch the pull request is against. But that’s not always a user error, one repo might simple have merged a few patches already.
Also, the pull request status needs to be different for each repo. One maintainer might close it without merging, since they agreed that the other subsystem will pull it in, while the other maintainer will merge and close the pull. Another tree might even close the pull request as invalid, since it doesn’t apply to that older version or vendor fork. Even more fun, a pull request might get merged multiple times, in each subsystem with a different merge commit.
Issues
Like pull requests, issues can be relevant for multiple repos, and might need to be moved around. An example would be a bug that’s first reported against a distribution’s kernel repository. After triage it’s clear it’s a driver bug still present in the latest development branch and hence also relevant for that repo, plus the main upstream branch and maybe a few more.
Status should again be separate, since once push to one repo the bugfix isn’t instantly available in all of them. It might even need additional work to get backported to older kernels or distributions, and some might even decide that’s not worth it and close it as WONTFIX, even thought the it’s marked as successfully resolved in the relevant subsystem repository.
Problem
Issues and merge requests (see https://gitlab.com/gitlab-org/gitlab-ce/issues/36280) can be relevant for multiple repos, and might need to be moved around. However they might need to exist at the same time in multiple places (see usecase above). Discussions should therefore not be disconnected, but rather be unified and synchronised.
Proposal
Discussion can become the single source of truth across multiple places, forging another deeper connection between projects.
This is quite a challenging feature and has multiple hard problems to solve. Also this issue can probably be divided up into 2 parts:
- issue discussions
- mr discussions
Value
- Being able to support really large projects, with advanced git flows, like the linux kernel git workflow
- Discussions become a single source of truth across multiple projects