[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Gitlab Evaluation & Migration
From: Wyatt Childers <wyatt710 () gmail ! com>
Date: 2019-02-23 21:12:08
Message-ID: CAGDkS-8Y0zb5UgQBiVt2HBbfaBCcMrX5nGDsp-vr=XVQcgh7ZA () mail ! gmail ! com
[Download RAW message or body]
I'm not an active contributor. I am a developer though, who's employer uses
gitlab... Not a huge fan. My main complaint is it tends to be slow, and I
find the UI a little less intuitive. Recently they even broke copy and
paste site wide on their instance -- which was very frustrating.
I recently stumbled upon this project: https://github.com/go-gitea/gitea
I would pose it as an alternative that's very familiar feeling to GitHub,
and written in a much more efficient language (Go vs Ruby), which should
result in a lower operating cost.
I want to be clear, I am very appreciative that many projects have been
working to evaluate GitLab, and I don't think it's the worst option. I just
wanted to pose this as well to the community as well. More informatively
than anything else.
Best,
Wyatt
On Sat, Feb 23, 2019, 9:14 AM Ben Cooksley <bcooksley@kde.org wrote:
> 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
> to
> > > 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
> extensively in this way. I don't think you're familiar enough with the
> Krita community 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 familiar with another workflow doesn't mean that the first
> thing is hard, and the 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
> submit patches for review without having push rights, a migration seems
> impossible. 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 patches for review.
> >
> > --
> > https://www.valdyas.org | https://www.krita.org
> >
> >
>
> Cheers,
> Ben
>
[Attachment #3 (text/html)]
<div dir="auto"><div>I'm not an active contributor. I am a developer though, \
who's employer uses gitlab... Not a huge fan. My main complaint is it tends to be \
slow, and I find the UI a little less intuitive. Recently they even broke copy and \
paste site wide on their instance -- which was very frustrating.<div \
dir="auto"><br></div><div dir="auto">I recently stumbled upon this project: <a \
href="https://github.com/go-gitea/gitea" target="_blank" \
rel="noreferrer">https://github.com/go-gitea/gitea</a></div><div \
dir="auto"><br></div><div dir="auto">I would pose it as an alternative that's \
very familiar feeling to GitHub, and written in a much more efficient language (Go vs \
Ruby), which should result in a lower operating cost. </div><div \
dir="auto"><br></div><div dir="auto">I want to be clear, I am very appreciative that \
many projects have been working to evaluate GitLab, and I don't think it's \
the worst option. I just wanted to pose this as well to the community as well. More \
informatively than anything else.</div><div dir="auto"><br></div><div \
dir="auto">Best,</div><div dir="auto"><br></div><div \
dir="auto">Wyatt</div><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Feb 23, \
2019, 9:14 AM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank" \
rel="noreferrer">bcooksley@kde.org</a> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Sun, Feb 24, 2019 at 8:06 AM Boudewijn Rempt <<a \
href="mailto:boud@valdyas.org" rel="noreferrer noreferrer" \
target="_blank">boud@valdyas.org</a>> wrote:<br> ><br>
> On zaterdag 23 februari 2019 18:58:46 CET <a href="mailto:stefan@derkits.at" \
rel="noreferrer noreferrer" target="_blank">stefan@derkits.at</a> wrote:<br> ><br>
> > "A lot" is probably a bit exaggerated, e.g. I don't really \
know where to<br> > > upload patches to Phabricator or create a pull request \
there, but do<br> > > understand how GitLab works.<br>
><br>
> I was talking about the Krita community, which uses Phabricator extensively in \
this way. I don't think you're familiar enough with the Krita community to \
make this comment. Also, not knowing some thing (how to find the Code Review link in \
the <a href="https://phabricator.kde.org/" rel="noreferrer noreferrer noreferrer" \
target="_blank">https://phabricator.kde.org/</a> homepage) while being familiar with \
another workflow doesn't mean that the first thing is hard, and the second one \
not.<br> ><br>
> > So I guess we have many different people in the community and many of<br>
> > them can get used to change.<br>
><br>
> Everyone can get used to change; as long as the thing remains possible.<br>
><br>
> > > * clone the repo<br>
> > > * hack<br>
> ><br>
> > * git commit<br>
> > * git push awesome-feature-branch<br>
><br>
> So, basically, what you're saying is that unless a person has push rights, \
they cannot collaborate? That's worse than I thought.<br> <br>
In the Gitlab world, people would fork the main repository, work on<br>
their changes there and then send a merge request.<br>
To make it absolutely clear, push rights to main repositories are not<br>
required under any circumstances to contribute to a repository in the<br>
Gitlab world.<br>
<br>
For KDE Developers of course, they'll have the option of either<br>
forking the repository (like anyone else would for making changes) or<br>
working on a separate branch within the main repository. How projects<br>
want to work is up to them indvidually, but both models work - only<br>
non-developers are required to use forks.<br>
<br>
><br>
> > * click on the link in the output<br>
> ><br>
> ><br>
> > > * add a bit of text explaining the change<br>
> > > * wait for me or dmitry to look at their patches<br>
> ><br>
> > One more step for the first creation of a merge request. Not that much<br>
> > different.<br>
> ><br>
> > > They don't have push access to kde's git server at all, so I \
guess<br> > > > 'git push my-fork HEAD' won't work in any \
case.<br> > ><br>
> > I guess this needs to change (with more fine grained permissions), the<br>
> > whole Merge Request System is based on merging other branches to \
Master.<br> > > Afaik uploading just a patch doesn't work in GitLab.<br>
><br>
> Well, that's too bad. Unless someone can explain to me how people can submit \
patches for review without having push rights, a migration seems impossible. 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 patches for review.<br> \
><br> > --<br>
> <a href="https://www.valdyas.org" rel="noreferrer noreferrer noreferrer" \
target="_blank">https://www.valdyas.org</a> | <a href="https://www.krita.org" \
rel="noreferrer noreferrer noreferrer" target="_blank">https://www.krita.org</a><br> \
><br> ><br>
<br>
Cheers,<br>
Ben<br>
</blockquote></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic