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.
Thanks. I don’t want to clutter this thread while diagnosing this. If this is a reproducible problem, it would be most helpful if you create a new bug to report it (this forum won’t let me link to it but the URL is https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug).
Alternatively, if you want me to do that for you, please hit me up at tfigueiro at gitlab.com.
I am pretty sure that GitLab is GDPR-compliant (since they have to comply with the GDPR on gitlab.com).
However, many self-hosted services are not GDPR-compliant, and GDPR-compliance is an important thing to check. So if Gitea is selected, it’s important to check for GDPR-compliance.
Then again, I am not sure if Blender’s website are currently GDPR-compliant either (the blender.org website doesn’t mention the right to lodge a complaint, for example), but that’s a different question.
The main thing I like about phabricator (edit: was ‘gitlab’ but I meant phab) are the code review features. It would be nice if those sort of features would be in the new system.
I do have a strong preference to not use the ‘ultimate edition for open source projects’ from gitlab. While I like the gitlab people and they’ve created a very nice system and their offer is very generous, and made with the right intentions, I still think it’s a dangerous route.
Companies are not constant things. If facebook or apple decides to buy gitlab (I don’t know if it’s currently possible, but anything can happen in tech-company land) you’re suddenly beholden to a less attractive party.
Also I think back to the whole linux-bitkeeper history and that was not nice at all, even though there were lots of nice people around.
So while I sincerely compliment gitlab with both their system and their good work in hosting open source projects I think blender is just too big for that. If you’re a small project that can easily switch to something else these sort of constructs are fantastic. If you are a juggernaut like blender not so much… (imho of course).
Just under 2 years ago, I looked into similar issues for the code hosting infrastructure for work. I ended up going with Gitlab for our setup.
Pros:
Unless something new has popped up in the last few months, practically, Gitlab is the only option that has a similar level of functionality (especially on the issue tracking / workboard front)
“GitHub” style issue management sucks, and doesn’t fit Blender’s development workflow or organisation. Practically, GitHub style issues are presented as a flat list, accompanied by an unordered sea of tags, and are nominally “searchable” using a very basic/anaemic search box that doesn’t inspire confidence in being able to find what you actually need or want. (From the looks of things, Gitea is one of those lightweight GitHub clones)
Redmine has a much more robust issue tracking system, along with decent search filters. The main downside is that, at least with the instance I worked with, it was really a “previous generation” tool (aka, clunky early 2010’s web-forms, and mostly only Issue Tracking + Wiki’s. Not sure about if it can even do code review / repository browsing, as we were using Gerrit for code review with various plugins). IIRC, Nathan / jesterking ran a test instance of Redmine for Blender about a decade ago, and IIRC it had performance issues with our bug tracker database from back then even, so I hate to think how it’d fare with the 2022 Blender Bug Tracker.
KDE seems to be another one of the big FOSS projects using a self-hosted instance of GitLab these days
“Open Source” programme for access to full features tier makes the necessary features for project management available without having to commit to significant recurring subscription costs (their prices are “per user, per month”).
Cons:
Licensing tiers / stuff like that are fickle, and change often. IIRC, some of those things need to be “renewed / reviewed annually”, so care is needed. Relying on the good favour of a 3rd party company (with all the various investment round + sharemarket listing stuff they’ve got going on) does present a level of risk that should be considered carefully.
Spam for self-hosted instances can end up being an issue / ongoing battle
For example, a local admin I spoke with had to basically turn off the ability to create new accounts. As an indication of the scale of the problem, for much of last year, a bunch of us were getting hit with multiple spam login/password-reset/lockout emails related to that instance, separate to the one we were using).
But, to be fair, this type of issue is also a problem that Blender’s Phabricator + Mediawiki instances have encountered, so it’s nothing new there.
The number of ways I’ve seen people screw up signing up to accept an invite to join an private project/group/repo is eye opening
The biggest downside is that Gitlab doesn’t really have Phabricator’s concept of allowing multiple “Projects/Teams” for a Repo.
For our setup, I ended up working around that by creating multiple nested “groups”, assigning folks to those, and creating “workboard only” projects to help get on top of it, but it was still a mess getting non-technical folks to navigate all that. (In particular, getting them to locate the workboards + wiki pages to get their bearings to the rest of the resources was a pain)
There are a bunch of clunky things in the UI, but these are generally small annoyances more than real deal breakers:
The UI for editing Title + Description for an issue is quite hidden / obscure, when compared to most other tools (i.e. a tiny “pencil” icon). I’ve seen lots of folks give up, and just write new comments everytime they want to do that instead.
(With the current versions) You need to reload a page before trying to edit a code-review comment, otherwise it loads an empty / zero-height box that you can’t resize.
Other little annoyances + sudden regressions like the comment-editing one pop up with every other update, and are fixed with yet another later update. (Apparently, you do also need to keep up with the release schedule, as skipping multiple releases and then trying to upgrade is apparently problematic - Disclaimer: I haven’t had to deal with this side of things myself, so that point might just be outdated heresay…)
An earlier poster noted the ability to define multiple workboards per repository. In my experience, I’d like to caution that that feature has been a bit half baked: Yes, you can define and use them. But, there are some glitches sometimes when you use them, e.g.
If you switch away from the main one, navigating to the workboards via the navlinks tree puts you back on the last one you used, and not a default one.
Also, the way that the Open/Closed issue columns works means that you do often end up seeing issues from other workboards showing up on unrelated ones, which can be a bit unsettling / confusing
Hopefully that offers some useful insights from someone who’s familiar with both Blender’s Phabricator and current Gitlab
One last thing I forgot earlier:
What are the main obstacles to continuing to use Phabricator, despite it being deprecated now?
I understand that web-facing tech does need a lot more churn + active maintenance to keep on top of dependency updates to apply security patches, etc., but what specifically means that the ending of official support pose a serious issue for Blender’s continuing usage of it?
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.
