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

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Andrius =?utf-8?B?xaB0aWtvbmFz?= <stikonas () kde ! org>
Date:       2019-02-24 20:31:15
Message-ID: 2158297.0NUtSQb2jY () laptop
[Download RAW message or body]


I use Gitea for my own arm64 server on SoC. In that case it makes sense as it
starts quicker and more importantly consumes less memory. So Gitea definitely
has its uses.

For KDE purposes, I think machine that hosts Gitlab will be more powerful anyway,
and it's probably more important that there is always upstream that can respond 
to our support requests. I guess KDE sysadmins don't want to again end up in
"Phabricator" situation where they don't get any support.

And regarding using Gitea vs Gitlab, there are more similarities between these two
as opposed to Phabricator than differences. There are some things in Gitea that
are unsupported in Gitlab and somewhat more vice versa.

Andrius

2019 m. vasario 23 d., šeštadienis 21:12:08 GMT Wyatt Childers rašė:
> 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
> >
> 

["signature.asc" (application/pgp-signature)]

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