---- On Tue, 26 Feb 2019 02:02:08 -0700 Eike Hein <h...@kde.org> 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
