<div dir="ltr">I think we will have to play around with it to see what it is capable of. There definitely seems to be forking and merge requests available in gitlab. <div><br></div><div>In about 5 minutes, I forked Kdenlive, made a change and committed it all from the invent site. I then submitted a merge request from my master branch to their master branch. I wouldn't be surprised if they could merge my change with a single button from the web UI.</div><div><br></div><div><a href="https://invent.kde.org/kde/kdenlive/merge_requests/35">https://invent.kde.org/kde/kdenlive/merge_requests/35</a> </div><div> <br></div><div><br><div><br></div><div><br><div><br></div><div><br><div><div><br></div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 15, 2019 at 10:21 AM Wolthera <<a href="mailto:griffinvalley@gmail.com">griffinvalley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Apr 15, 2019 at 3:42 PM L. E. Segovia <<a href="mailto:lsg@amyspark.me" target="_blank">lsg@amyspark.me</a>> wrote:<br>
><br>
> Hey all, hey Wolthera,<br>
><br>
> I'm glad to hear we're moving out of Phabricator. Having said this, as a<br>
> GitHub user, I'm more used to the merge request approach. Ideas:<br>
><br>
> * We'd need to document how to fork/clone, download the repo, change<br>
> branch, etc. (University experience tells me this is not straightforward<br>
> for beginners.)<br>
<br>
Yes, we'll need to wait till the migration is complete to see how this<br>
will work in the end.<br>
<br>
><br>
> * Not workflow-related, but some serious CI integration would be helpful<br>
> to let them know if their patch is acceptable.<br>
<br>
Ben says sysadmin intends to use gitlab's ci instead of jenkins ci(but<br>
nightlies will still be done on jenkins) but they haven't finalized<br>
the plans yet.<br>
<br>
><br>
> * Merge-by-email seems a far lower entry barrier than the proposed<br>
> merge-request workflow, and also more similar to the current Phabricator<br>
> approach. I think we could expand a bit on the Git-email docs from<br>
> <a href="https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Email" rel="noreferrer" target="_blank">https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Email</a> .<br>
<br>
Ooh, thanks!<br>
<br>
><br>
> Another question-- can we keep using tasks? I found them particularly<br>
> useful to review ideas without involving code.<br>
<br>
Yes, we will keep using tasks/issues. There's just too much pre-coding<br>
design going on in Krita to not have them :)<br>
<br>
><br>
> Best regards,<br>
> Leonardo<br>
><br>
> --<br>
> Leonardo E. Segovia<br>
> <a href="https://www.amyspark.me" rel="noreferrer" target="_blank">https://www.amyspark.me</a><br>
<br>
<br>
<br>
-- <br>
Wolthera<br>
</blockquote></div>