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

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2019-02-23 19:13:57
Message-ID: CA+XidOHBgotFrHzyPX-vh+SEpjxxy_rsX=u-6Efe2WOMHbEiUw () mail ! gmail ! com
[Download RAW message or body]

On Sun, Feb 24, 2019 at 8:06 AM Boudewijn Rempt <boud@valdyas.org> wrote:
>
> On zaterdag 23 februari 2019 18:58:46 CET stefan@derkits.at wrote:
>
> > "A lot" is probably a bit exaggerated, e.g. I don't really know where t=
o
> > upload patches to Phabricator or create a pull request there, but do
> > understand how GitLab works.
>
> I was talking about the Krita community, which uses Phabricator extensive=
ly in this way. I don't think you're familiar enough with the Krita communi=
ty to make this comment. Also, not knowing some thing (how to find the Code=
 Review link in the https://phabricator.kde.org/ homepage) while being fami=
liar with another workflow doesn't mean that the first thing is hard, and t=
he second one not.
>
> > So I guess we have many different people in the community and many of
> > them can get used to change.
>
> Everyone can get used to change; as long as the thing remains possible.
>
> > > * clone the repo
> > > * hack
> >
> > * git commit
> > * git push awesome-feature-branch
>
> So, basically, what you're saying is that unless a person has push rights=
, they cannot collaborate? That's worse than I thought.

In the Gitlab world, people would fork the main repository, work on
their changes there and then send a merge request.
To make it absolutely clear, push rights to main repositories are not
required under any circumstances to contribute to a repository in the
Gitlab world.

For KDE Developers of course, they'll have the option of either
forking the repository (like anyone else would for making changes) or
working on a separate branch within the main repository. How projects
want to work is up to them indvidually, but both models work - only
non-developers are required to use forks.

>
> > * click on the link in the output
> >
> >
> > > * add a bit of text explaining the change
> > > * wait for me or dmitry to look at their patches
> >
> > One more step for the first creation of a merge request. Not that much
> > different.
> >
> > > They don't have push access to kde's git server at all, so I guess
> > > 'git push my-fork HEAD' won't work in any case.
> >
> > I guess this needs to change (with more fine grained permissions), the
> > whole Merge Request System is based on merging other branches to Master=
.
> > Afaik uploading just a patch doesn't work in GitLab.
>
> Well, that's too bad. Unless someone can explain to me how people can sub=
mit patches for review without having push rights, a migration seems imposs=
ible. It's already hard for some people to understand they need to create a=
 KDE identity, but once they've got that, they should be able to offer patc=
hes for review.
>
> --
> https://www.valdyas.org | https://www.krita.org
>
>

Cheers,
Ben
[prev in list] [next in list] [prev in thread] [next in thread]