Developer.blender.org - Call for comments and participation

Technical Feedback
41

https://about.gitlab.com/ works for me, and my browser also matches the minimum browser requirements.

42

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. :bowing_man:

1 Like
43

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.

1 Like
44

Note that Gitea might also join the Feediverse at some point: https://social.gitea.io/@gitea/107576791626052697

This opens very interesting possibilities and could, depending on how it’s implemented, be quite convinient for developers.

2 Likes
45

Gitea also has a nice Android app, not that it matters for the core development but this is a nice to have.

A free/paid, open-source Android native client for Git repository management tool Gitea

Another self-hosted solution I tried was https://gitbucket.github.io/ It might be a decent one to take a look at as well since it has a nice plugin system http://gitbucket-plugins.github.io/

46

I don’t really have a preference (yet).

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).

6 Likes
47

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.

    1. 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.
    2. 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 :slight_smile:

8 Likes
48

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?

8 Likes
49

global search (too much UI based and keyb unfriendly) doesnt provide with the issue specific filters like labels, or other such stuff available in issue search etc

epics

i did not have access to those, so, dont have an intuition at how they work, that’s why i did not mention that

scoped labels

i know about it, but scoped labels get lost in plathora of other labels, and arent shown upfront. in the issue list. the status thing is wanted to be a first class citizen (means shown at special places in the user interfaces and other such specificities), not a generic label

not sure what “mentioned upfront” means

“mentioned upfront in the issue list” means in the list where you search for issues (had given example of one which’s shown there “closed (moved)”)

deprecations

no, i was not talking about deprecations. i have tried filling the issues on gitlab project - several issues, each on different matters, and my experience was extreeeeemely poor.

50

Here’s a list of things that kind of suck with Phabricator (and that a replacement should do better):

  • The workflow feels very outdated. Why use a seperate tool to create and upload patches? Imo the pull / merge request approach using git branches is more standard and has better tooling / ide support.

  • There is no CI integration in Phabricator. It would be good to see if a patch (pull request) passes checks / compiles before reviewing it. Or allow certain patches to automatically apply once they pass CI.

  • The code is not centerstage: it’s kinda difficult to just read / browse the repositories online. Phabricator instead focusses on patches on the frontpage.

  • There is no code editor on Phabricator. You cannot quickly fix a typo or write documents without first having to check out the source and preparing a patch.

  • The developer facing documentation is not on Phabricator but on a seperate MediaWiki instance.

51

What are those features that Gitea and Gitlab Community Edition are missing and that would have to be coded by BF?

1 Like
52

There are some questions which I assume others have looked into relating to the health of the project we would switch to.

  • Is gitlab profitable? As far as I can tell not-yet, making it more of a risky choice…
    I can only assume the company behind Phabricator wasn’t profitable (enough), although there could be other reasons.
  • There are other alternatives, some have been mentioned here - is it the case that these projects are significantly smaller/alpha-quality/less-healthy/missing-features.
    At a glance - Kallithea, Gitbucket are in the same ballpark as Gitea.

I’m wary of selecting a project based on some nice-to-have features when the overall health of the project may be in question. While we can’t know for sure how things go in the future - some questions that come to mind:

  • If in n years time gitlab needs to be profitable, how might this impact us? (apologies if it already is, the only information I could find online pointed to it not yet being profitable)
  • What is the motivation for maintaining gitea? (is this developed by enthusiastic volunteers? are there businesses behind this? … etc).

These questions probably don’t have simple answers, even so, I’m more concerned about the health of the project we move to than individual features.

9 Likes
53

This is actually something which I think is an advantage. Pull requests only work if the person doing the pull request has his git repository shared online. Which would mean that either developer.blender.org needs to host git repositories for everybody, or people need to publish their repositories themselves with all the hassle that brings.

I do dislike that arc diff squashes all commits into one, though.

54

I think GitLab would be the least risky choice in terms of health of the project, because there are many other closed and open source projects relying on it and there is real funding behind it. If GitLab the company goes under I think it’s likely to continue in some other way.

The alternatives seem to be mostly driven by volunteers and there are few public instances, seemingly none used by a big open source project. Gitea development for example still happens on GitHub, which is understandable but shows the maturity of the project. I think such projects are much more likely to become unmaintained, though I hope they don’t.

In terms of features I think it’s mixed, I think GitLab is clearly better for us as-is, but also would be harder to improve to suit our needs.

2 Likes
55

If I understand the situation gitea is in, then it is not driven by volunteers but they have 3-4 full-time developers working on it.

These are paid via a fund like we do with Blender.
Most of the funding seems to come from small to medium sized companies. Last time I looked the majority of sponsors seems to be located in China.

There is a publicly viewable internal vote every year were they decide who should get funds to work full-time on the project. There seems to be more willing developers than there is funding so IIRC, they also have a bounty system where people can chip in for funding developers outside of the core team to finish a task.

hosted on github and not self-hosted

There is a ticket about this on their github page.
The gist of it is that they have been able to self-host with all the features they need for a long time. They have even done so will all their repositories besides the main “gitea” repo. (They have around 10 other repositories besides the main one.)

The two major reasons for this seems to be two fold:

  1. The cost of self hosting the main repo would be quite large. They could do it, but why spend money and admin power on that instead of hiring more core developers? Most of their clients don’t care if the development happens on a self-hosted instance. They only care if the product itself is good enough.

  2. Self hosting will make the project more isolated as it won’t then be part of the github developer ecosystem. Perhaps not a big downside. But it would mean potentially less community engagement both in the issue tracker and pull request wise.

To me, even if gitea doesn’t have the same kind of funding that gitlab has, I think it is a safer bet because it is fully open source. (And there seems to be less “vendor lock in” than with gitlab because it goes all in on supporting 3rd party CI systems etc)

I have had experiences in the past of going with half open solutions. Those where bought up by Oracle and the licensing got restrictive as heck while the free tiers were swiftly eliminated and prices jacked up. Migration was very painful and costly.

I don’t want to see blender getting into such an uncomfortable situation.

11 Likes
56

From Gitea - Open Collective I understood the funding was small, but if there are 3-4 fulltime developers (presumably from other sources) that’s more reassuring.

1 Like
57

Unfortunately this would mean the Gitea funding could be affected significantly by increased western sanctions, which seem rather likely looking into the future. In general the Chinese economy is hard to predict. OTOH if a big player like Blender switches to Gitea that may help diversify their funding.

I think it’s very hard to predict the longer term health of the choices we have, so doesn’t seem like something we can give much weight in our decision making. Worst case is we have to do another transition in a few years, but since the platforms would use the more common github-like workflow, that might be less painful than porting from Phabricator. There are plenty of other things that may go wrong that could lead to that scenario.

58

Note that I could be remembering wrong, so if it is important, we should double check so that it is correct.

This is what I remember from when I did some initial research last year, just to be clear.

59

I think that 2. also applies to Blender.

There is an argument to be made for moving to GitHub.com, as

  • from all of these options, it is the most likely to stay operational
  • it already has significant buy in from the wider open source and FOSS community
  • it would not require Blender to host user forks or allow any contributor to branch - either of which would be necessary to allow for the Pull Request based workflow that Github, Gitlab and Gitea are build around

IMO this should be seriously discussed and not discarded for ideological reasons. Even if GitHub is deemed too proprietary, I think it would be worth it to evaluate what openness in this context here means and to what extent it can be achieved / what parts of it are worthwhile pursuing.
Does it matter what software runs on the blender.org servers?

2 Likes
60

Unless @Ton radically changed his views on this recently, i don’t see github being an option.

5 Likes