[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Nate Graham <nate () kde ! org>
Date:       2019-02-26 19:38:46
Message-ID: 1692b510e0a.11eaa858e7686.807306018362216387 () kde ! org
[Download RAW message or body]




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


[prev in list] [next in list] [prev in thread] [next in thread]