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 <bcooks...@kde.org wrote: > On Sun, Feb 24, 2019 at 8:06 AM Boudewijn Rempt <b...@valdyas.org> wrote: > > > > On zaterdag 23 februari 2019 18:58:46 CET ste...@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 >
