[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]