From kde-devel Tue Feb 26 19:38:46 2019 From: Nate Graham Date: Tue, 26 Feb 2019 19:38:46 +0000 To: kde-devel Subject: Re: Gitlab Evaluation & Migration Message-Id: <1692b510e0a.11eaa858e7686.807306018362216387 () kde ! org> X-MARC-Message: https://marc.info/?l=kde-devel&m=155120996200506 ---- On Tue, 26 Feb 2019 02:02:08 -0700 Eike Hein wrote ---- > How would GitLab impact the kdesrc-build experience? So this is the current kdesrc-build experience: 1. kdesrc-build [thing] 2. cd ~/kde/src[thing] 3. arc feature my-awesome-patch 4. Start hacking 5. kdesrc-build --no-src --resume-from [thing] 6. [test and make sure it works] 7. arc diff --create It's really pretty nice. But Gitlab has a fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, people without commit access won't just be able to start hacking with the source checkout that kdesrc-build downloads, or else they won't be able to push their branch to any remotes and create a Merge Request. Since Merge Requests from people without commit access have to come from a private fork, that means that in the above model, they need to use some web UI to first create a private fork, and then somehow tell kdesrc-build to check that out rather than the original repo. Alternatively, perhaps kdesrc-build could check out the source from the original repo, but automatically create a second remote in each repo that corresponds to the private fork? Then people could hack in the original repo, but push their branches to the private remote fork for the purposes of creating a Merge Request. All of this is probably technically solvable, but it seems like it will take some doing to ensure that the user experience is as good as it currently is today (IMO, of course!). Nate