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