I’m DevOps expert for an Open source company and I installed and used both gitlab and gitea for years.
What I can say, gitea is very easy to scale (especially on kubernetes) and I really appreciate that I can use others CI/CD tools like drone.io (self hosted) with more ease. Gitlab is able to use external CI/CD but it’s a bit more tricky. I consider that having the choice to externalize this is more efficient and add freedom.
Gitlab is very hard to maintain in comparison of gitea. Gitea is also lighter and faster to start (very interesting if you use an elastic scaling).
Gitlab has got more add-ons like scrum board for example. But I prefer to not centralize everything in one service (same argument that CI/CD).
Gitlab offers more options like internal pipelines, kubernetes manager, or docker registry… Do you really need it inside the git manager?
Don’t undervalue the benefits of exposing the “black box” of development to a wider audience. Everyone is super familiar with GitHub, it’s the de-facto standard. Everyone has a GitHub account. It is rough around the edges in terms of some of its workflows but I think those will be true for any GitHub clone (GitLab, Gitea, Gogs, etc.). I don’t love everything about the community development experience of GitHub but making it widely accessible by millions of visitors will be seriously beneficial to the momentum of the project. Lots of new developers who were intimidated by Phabricator will try to set up the project and start tinkering with it. I assume the reason it wasn’t mentioned in this video as a contender is because of the “Microsoft cooties” but Microsoft has truly shown that they are keeping a hands-off approach, except in beneficial ways where they throw money at defending takedown requests (the FFmpeg scandal) or matching sponsorship donations. GitHub is a platform, not part of the Blender product, so it doesn’t have to be open source directly because you are using it, not developing it. Blender is the product, not the platform it’s built with. I also believe Blender is at a scale where GitHub would be happy to work with Blender to alleviate any concerns and develop small-to-moderate-sized features requested by the Blender Foundation. So while it can be tempting to self-host a GitHub clone, stability and approachability by a massive audience is way more important than “saving face” by using the de-facto standard that has the unfair stigma of being owned by a company that used to be evil, a decade ago, but has shown to be only benevolent to the GitHub platform.
The thoughts shared in the video about GitLab CE, Ultimate, and the issue open core can pose to open source contribution were enlightening and a strong argument. Thanks for that !
If Blender Foundation has the resources to contribute to Gitea, fix paper cuts like the file upload, develop missing features and support the project in the long term, it could be an amazing contribution to the FLOSS community and all projects aligned with Blender’s core values.
Using propietary solutions is totally out of the question. It’s not just a technical standpoint, is also a moral one. Blender endorses FOSS, it’s a vision, a statement. To use a privative solution just because it’s better than the existing FOSS solutions betrays that vision.
Blender may help here make a solution better and more useful, FOSS pushing each other. You may disagree with this vision, but the statement is there and they’ve followed that since forever, even meaning staying out of Discord for the official channel, etc.
It’s worth mentioning that Blender would easily qualify for GitLab’s GitLab for Open Source program, which provides Ultimate tier features and a generous number of CI/CD minutes.
So, don’t limit your evaluation to community edition features of GitLab.
Code review in general works well, with the ability to have a discussion on a line of code is nice, suggest changes, the other person to mark them as done.
Ability to comment on lines of code.
Command line tool (arc) for downloading patches.
Workboards / project tagging is quite nice.
Phabricator Cons
Creating new repositories was not something we could easily do - not even admins. …at least the way we had this configured.
Notifications Either I’m flooded with emails or turning them off which also isn’t great.
Auto-completing developer names often fails. This may sound small, but if your assigning reports / subscribers often and it’s never completing some peoples names it gets quite frustrating.
No online file editing. I wouldn’t use much personally, but I think others miss this, it’s nice to support drive-by contributions.
I’ve used gitlab & installed & tested gitea locally, my impression is both involve making some compromises but both are usable (no deal breakers as far as I can see).
Personally as long as code-review works well and I can download patches with a command line tool, I’ll be able to live with whatever solution we go with.
It’s a shame the open core model of gitlab is so restrictive (some arbitrary limitations that impact us), so unless there are concerns with the health of the gitea project, I’d rather opt for something fully open.
May I suggest that instead of modifying the code to enable paid features, Blender joins the GitLab for open source program?
While the Community Edition is open-source, and you’re allowed to modify it, doing so to enable the Enterprise features violates the subscription terms because you will activate code under the ee/ directory, which is covered by a different license (I’m a new user and can’t post 2 links in a message, but you can browse and find the LICENSE file under ee/ yourself).
Disclaimer: I work for GitLab. Opinions are my own. No one in GitLab told me to participate on this thread.
My answers here assume that Blender applies to and is accepted to the GitLab for Open Source program. This would grant Premium and Ultimate features to the project.
Note: apologies for not including links to everything. I am only allowed 2 links per message as I am a new user.
Integration with elasticsearch provides advanced search which does search in comments, code, issues, epics etc. You can also search in specific issues as the global search is context-sensitive.
This works out-of-the-box on GitLab SaaS (.com) for Premium projects.
Scoped labels (link removed, sorry) works well for these purposes.
Duplicate issues are also marked as such. I’m not 100% sure what “mentioned upfront” means - I usually see it marked as such at the top, next to the issue title and status.
Vote for issue 23906 in the gitlab-org/gitlab project (link removed, sorry)
If anything is broken, I urge you to report it and we’ll look into it. We have deprecation guidelines (link removed, sorry), so anything that hasn’t been deprecated or removed is supported; we’ll accept bug reports, and prioritise accordingly.
From what I could tell the implementation of this particular feature is not in ee/ but fully in app/helpers/form_helper.rb. But regardless, it’s not great to deal with this kind of license restriction, and there’s probably other features that will certainly have this problem.
I am not sure if phabricator can already do it or not, but it’d be good if the new platform could restrict certain user groups for commenting on certain tasks. There are design type tasks, implementation type tasks and so on. Often, regular, non-developer users end up adding comments under implementation tasks where specific code-related things are to be discussed.
This would help both developers keeping the comments under the tasks clean, as well as help to direct users to the tasks where non-developer comments are acceptable.
Ideally, there could be also certain trust levels, which could prevent the occasional spam outbreaks, which phabricator tends to suffer from. I’ve seen spam bots not just adding comments, but even changing statuses and priorities of the tasks. Random spam bot should not be able to make an account and immediately find a random task and switch its status from closed to high priority
I stumbled across the video mentioned above. I was also involved in Blender development
over 20 years ago (before Blender became open source).
Privately (and professionally) I have been using Bitbucket, GitHub, GitLab, Codeberg (gitea), and recently I found:
From there you have links to e.g. a website, but also to sources, which
can be one (but also many) git repositories. They make it easy to work
with mailing lists:
My project is Rust based, but I’m sure it can handle C/C++ well.
I think making Blender and all it’s dependencies work nicely with continuous integration will be a challenge, especially if Blender ever
wants to go back and follow the vfxplatform suggestions (again),
but once solved, this might be actually easier than Travis CI or others.
Anyway, enough information for now. I think this a big chance to question
development tools and stick with 100% free and open source software
even for all tools involved.
Disclaimer: I work at GitLab and I’m involved with the GitLab for open source program. Nobody at GitLab told me to post here, however. I’m doing so because I’m a big fan of Blender and I was excited to hear that the Blender community is considering GitLab.
If you’re considering GitLab, I encourage you to apply to GitLab for Open Source Program to get all of GitLab’s top-tier features for free.
First of all: at all the gitlab people that have shown up here, that is a very generous offer, appreciated!
however some caution/restraint may be needed from the blender side, not all is rainbows and unicorns with this offer:
Biggest danger with commercial entities having well meaning programs like 'X for opensource" that offers their premium feature for free, is that over time sentiment of the generous entity may chance, new management may come in that see things differently or a merger happens with some other company that likes to take things in a different direction. Just because they are nice to us right now, doesn’t mean they will be in the future.
Gitlab specifically has axed parts of their pricing tiers in the past for not meeting the hurdle rate it expected [1] this combined with the terms of the Gitlab for opensource program [2] stating
Acceptance into the GitLab for Open Source Program is at GitLab’s sole discretion, and we reserve the right to terminate the Program, or change the Program requirements, at any time.`
Nothing would prevent Gitlab after 6 months to go, we’re done here, we’re no longer doing the Opensource program, y’all need to upgrade to the $19/month user plan starting next monday, also the $19 plan is now the $49 plan.
They probably won’t, but they can, and that risk cannot be taken lightly from the blender side, with phab we at least have period where we can look for something else at our own pace, gitlab can turn off the lights “at any time” and this should not be ignored while selecting a new platform.
Even when we quite clearly spell it out what is expected, some users still do it, for instance T93220 is pretty bad in this department, it’s not common, but T93220 is also definitely not a one off incident. Big feature tickets like rewrites, HIP support, etc have this problem more than “this button is off by 2 pixels” style tickets…
Yes, exactly, so am I. That’s why I proposed this. I myself would like to avoid causing developers trouble by commenting under the tasks I am not supposed to.
I agree it’s not ideal. I’m not exactly sure what 1-line change you had in mind, but there’s a chance that it may activate code that is under a different license.
In any case, if the community decides in favour of GitLab (), it seems reasonable to apply for the Open Source program, and then we don’t have to worry about changing code to activate features.
Good luck with the decision and, if there are any questions for GitLab, please tag @gre9 or myself.
for issue 23906 in the gitlab-org/gitlab project (link removed, sorry)
), it seems reasonable to apply for the Open Source program, and then we don’t have to worry about changing code to activate features.