Developer.blender.org - Call for comments and participation

Technical Feedback
61

ok, i guess if we take that as gospel, that also outrules gitlab premium edition.

maybe I’m mistaken, but from quick googling i don’t think either gitlab or gitea allow you to upload patches. So how will the development workflow in the future look like?

i guess there would have to be some access control with one role that would allow any user to create a branch, but only be able to make commits on own branches.
and another role for trusted users who are able to make commits on any branch.
I know that in GitLab you can protect certain branches, but I don’t know if there is a way to whitelist the branches a user is allowed to commit on.

alternative to access control would be to allow anyone to fork - but does BF want to store all of the user forks? Maybe pull requests from other hosted copies of the same git repo can be made - but that would just mean that users fork on github and then make the pull request on gitlab / gitea (if that even is possible)

to be honest i dont know what you can setup with build in tools in gitlab (or gitea) and what kind of stuff would need custom stuff. but i think this is the aspect that requires most attention rn, because afaik the self hosted versions of gitea and gitlab are designed to be run within an organisation, where you can have a base level of trust against users.

62

Initially there should be some clearing about the self-hosting option.

  • Self hosting: If strategically, is for the best interest of Blender Foundation, and also with extensive customization, it would meet the needs of the core developers in a better way.
  • Thirdparty service: If Blender Foundation, has no problem at all either, with self hosting either service-based hosting. It means that service-based hosting wins because it eliminates in-house maintenance.

In other way of thinking, it can go like this having a decision matrix and you attach points (backed with some fact). You can play with this diagram and expand as needed, do your own experiment and see if it works.


       | business  |            |  important | advanced |       | 
       | stability | popularity |  features  | features | other | score
       |---------------------------------------------------------
gitea  |    ?      |     ?      |            |          |       | 
github |    10     |     10     |            |          |       | 20... 
gitlab |    ?      |     ?      |            |          |       |  
other  |    ?      |     ?      |            |          |       |

A little more info about the criteria:

  • business stability: most important is that if the company has completed a the full cycle. As for example why github is a [10] because has completed all of the business phases (startup/growth/acquisition) and now it has settled for lifetime, as long as it remains popular it will remain as it is without surprises. While in contrast other companies, are experiencing growth-antagonism phase right now, they have future ahead of them, they could get a [8] or [9] etc.
  • popularity: not to say it intuitively, but looking at the cold data is even more clear. https://trends.google.com/trends/explore?geo=GR&q=github,gitlab,gitea but the point is not to use a marketing strategy exactly - we are not selling donuts, rather than consider if it actually popularity plays a role whatsoever, how popularity translates better to the specific needs of Blender?
  • important features: these are must-have git features that core Blender developers need. In that regard everything gets a [10]. However this brings another aspect, of whether or not self-hosting gets a [10] while other service-hosting drop points.
  • advanced features: same as before, but these are nice-to-have features however they make a clear difference and cover some very specific needs that Blender developers know they want. Also if these features are solved with self hosting it means that you create a new entry vertically (self-hosted-gitlab) and set it to a [10].
  • other: use this to expand with many more aspects if needed
1 Like
63

There aren’t that many options as far as I can see. To my surprise there is no “truly” open solution which appears very future proof. The point Ton raises is certainly important. It is still worthwhile to weight it against the cons of the other options.
He made the point when Phabricator was the number one option for Blender. With that one gone, the whole balance changes quite a bit.

64

Contrary to the good points about how widespread it is, GitHub is prone to political decisions.

Let’s assume a hypothetical situation where one of the allies of the USA, countryA is in a conflict or a war with another nation, countryB. The US government orders GitHub to block all the users and the activity from countryB. This does not sound very unlikely nowadays. And by law Github followed such orders in the past.

We know that Blender has a lot of contributors from all over the world. Self-hosting the development backend and the frontend is the only neutral solution in these times.

On the other hand the new backend could allow logins with Github and Gitlab accounts, that might be a good compromise.

8 Likes
65

I don’t really get what that would accomplish? It would not really make pulling from github/gitlab easier I think?

66

It would make so that people with those accounts would not need to create individual Blender accounts to contribute on developer.blender.org. It is just a convenience thing.

2 Likes
67

I would like to add bundled add-on development to the discussion. Has it been considered at all when looking for a new platform? Should it remain as one repository with everything lumped in together, potentially with one main “issue” for each add-on to keep track of things, or should each add-on have a separate repo for its development?

5 Likes
68

Just wanted to drop a note here that I’ve been following the discussions going on here and am deeply thankful for the amount of insightful views that people are providing on all manner of aspects. Sorry for having been quiet about that so far.

A big part of what I’m doing is collecting and collating different concerns and considerations that people have about what is good/bad/ugly about the options that we have available.

I want to take a moment to address a recurring theme in the discussion above, however, which touches on the subject of licences and openness.

It’s no secret that Blender has a proud history and culture revolving being Open Source. This is true for Blender and its related tools and projects as much as is possible. This is of course not accidental.

For this reason, preference goes out to seeking solutions that are fully open source if those can be made to fit the needs of the development community. This is not an ‘at all costs’ approach, however, but should be seen as a strong internal compass.

For that reason, for example, running on a full Github setup is an unlikely way forward. But neither is it impossible if other routes turn out to be fruitless. The process right now is geared towards evaluating what’s out there in an honest manner. The comments, reports, suggestions and concerns above are helping in this a lot.

Cheers,

19 Likes
69

yo, i have an idea, idk if its possible but what if you use discourse as the frontend and throw in some bot accounts to interface with a git backend?

70

Since no one has commented on this yet, I’m going to guess that it hasn’t been discussed very much yet and y’all want to hear my thoughts on it :wink:

Blender’s bundled add-on development is a bit of a mess currently IMO, add-ons generally don’t have a central landing page where you can see what’s happening with them, issues and diffs are all lumped in together, if the development isn’t being conducted on some external repository somewhere, and developers with commit access can change bundled add-on code without the author’s knowledge or consent (this isn’t to say that contributions aren’t welcome, but it can cause problems like ⚓ T95962 Sapling Addon now broken because of "SPDX-License-Identifier" header).

Since it seems that Blender will be adopting the fork/pull request paradigm, my current thinking is that I would like to see each bundled add-on get it’s own repo to manage development (bugs, tasks, landing page, PRs, etc.), have scripts/buildbot incorporate the master branch from each of these into the daily builds/releases, and a central listing of bundled add-ons so that the repos are easily findable. Or perhaps bundled add-on development should move entirely to external repos on GitHub, GitLab, Codeberg, etc., but then there is the challenge of synchronizing them with the rest of Blender.

Now I know this doesn’t directly help with picking the new development platform, but I think this is a good time to discuss it and to keep add-on development in mind when looking at the different platforms in case one platform is better suited for something like this than another.

Also, how bundled add-on development proceeds will be influenced by the new policies that have been made recently, and that are hopefully being discussed and clarified here Add-ons Policy Clarification/Discussion so feel free to chime in there if anyone has any thoughts on that as well.

4 Likes
71

Some critical issues have not yet been raised, which can all be encapsulated in the form of the GNU Ethical Repository Criteria. There are also some evaluations by these criteria, although the list of evaluated sites and software is far from complete.

Blender is a flagship free software program and should be a shining example of freedom. Relying on proprietary software, no matter how much the proprietors claim to be friendly to “open source” or want to give a discount for their proprietary software, is a complete betrayal of this goal of leading by example. No matter whether the entire platform has critical freedom issues (and privacy issues for that matter), eg. Github, or whether the software is only partially free, eg. GitLab, anything less than 100% freedom is a joke. Both of these sites currently score an F (unusable) in the GNU ERC, the worst possible grade.

Should the Blender project self-host or use an existing platform? Ideally the former, as this allows the Blender project to control its own infrastructure, software, and computers. The latter is okay, but not ideal, as it would mean the Blender project would lose a lot of the aforementioned control.

In any case, contributing without an account, anonymously over Tor, and without running JS, especially not proprietary JS, are an absolute bare minimum, which as I mentioned previously, is all encapsulated in the GNU ERC.

I vow to delete this account once this public discussion is concluded, and I resent having to make it in the first place in order to participate in this discussion. If I refused to make a temporary account, who knows whether anybody would have raised the issues I have, and as a result the final decision may have been disasterous.

Forges which allow communication by email are a solution, which leads me to lean towards self-hosting SourceHut as a preferred option, although it has a few issues which need fixing first, namely that it recommends non-libre OSs in its CI features and that it has not had an official “stable” release yet, although it’s already rock-solid.

2 Likes
72

wasn’t Sourcehut the one that got its grade lowered by the FSF because it didn’t call linux “GNU/Linux”?

73

To clarify, Linux is a partly proprietary kernel and GNU+Linux is an OS. Linux-libre is a 100% free version of Linux.

Referring to the GNU+Linux operating system as “Linux” is incorrect, and as such SourceHut received a lower score in its evaluation for making this mistake.

74

In my opinion, being open should be a criterion, not a requirement.
I understand that there are people who think like that. I clearly disagree with it though. Yes, the openness of Blender is important, but artificially trying to make it solely rely on open software appears counterproductive to me. First, it already heavily relies on and uses proprietary software. It runs on proprietary operating systems and uses proprietary drivers.
The decision here is regarding where the development should be coordinated. From my point of view, if they were to pick a purely open solution, there would be a huge risk involved. It is likely that a lot of work would be needed just to get something that works for them. At the same time, the risk is larger they would need to switch to another platform again.
Their primary goal should be to develop Blender. If they can do it purely with open source software, perfect. If it would take a huge effort or risk to do so, it makes way more sense in my opinion to use proprietary software.

1 Like
75

artificially trying to make it solely rely on open [sic] software

On the contrary, Blender is free software and should be developed in freedom; any attempt to make its development rely on proprietary software would be artificial.

First, it already heavily relies on and uses proprietary software. It runs on proprietary operating systems and uses proprietary drivers.

One can run it in freedom on 100% free operating systems like Parabola; using proprietary software is optional, as it should be. I wouldn’t particularly disagree if you were to propose removing support for proprietary systems and drivers, however, because that would free up time to spend improving support for free systems and drivers.

From my point of view, if they were to pick a purely open solution, there would be a huge risk involved.

On the contrary; using a proprietary or otherwise non-freedom-respecting platform or software would be a huge risk because control and freedom is lost. In other words, the Blender project would be at the mercy of the proprietor instead of independent, free, and in control as it (largely) is at the moment.

It is likely that a lot of work would be needed just to get something that works for them.

They already did it once with the current self-hosted infrastructure setup; I trust they can migrate to a different setup.

If it would take a huge effort or risk to do so, it makes way more sense in my opinion to use proprietary software.

Using proprietary software is a risk. Why put oneself at the mercy of a proprietor?

76

@Ton, in the interest of securing freedom for the future of the development of Blender, I think you should weigh in.

77

Blender would not rely on it. If issues occurred over time due to the proprietary nature of the platform, they could just switch to something else.
From my point of view, the number one priority should be the sustainability, meaning the chance of being able to use the platform as intended in the long run. If the risk is smaller on a proprietary platform (no matter how proprietary it is), that should be the go to solution. If there is an open source solution fulfilling the requirements, even better, but that doesn’t seem to be the case.

They are currently using an open source solution which was abandoned. So there is clearly a risk when relying on open source too.

1 Like
78

Blender would not rely on it. If issues occurred over time due to the proprietary nature of the platform, they could just switch to something else.

Ever heard of vendor lock-in?

If there is an open source [sic] solution fulfilling the requirements, even better, but that doesn’t seem to be the case.

On the contrary, SourceHut is the fastest, (anecdotally) most stable, most usable (working efficiently via email) and most freedom-respecting and ethical option at the moment, aside from Savane (which I wouldn’t propose using because it’s technically inferior to SourceHut), scoring a B on the GNU ERC.
(The issues it has which I previously mentioned in other posts can be fixed relatively easily.)

They are currently using an open source [sic] solution which was abandoned. So there is clearly a risk when relying on open source [sic] too.

There is always a risk, it’s software written by humans who make mistakes after all! Imagine if the current solution were proprietary, the Blender project would have no choice but to switch away from it, but since it is free, they had the option available to fork and maintain it, which is an advantage over if it were proprietary.

79

Yes, not sure why it would apply here though.

Again, I believe if there is an open source solution which can be adapted to fulfill the requirements, which appears to be sustainable, that would likely be a good option.

Even if they have the choice, I don’t see it being a good usage the available resources to maintain this sort of project in the long run.

80

Yes, not sure why it would apply here though.

It applies because the Blender project couldn’t “just switch” if it migrated its infrastructure over to a proprietary platform. It is not always possible to export data, eg. bug reports, conversations, messages, CI scripts, etc. from such services which are designed to lock you into their infrastructure. Some even start charging money after a while, it’s a classic bait-and-switch scheme.

If the developers of such hosting sites are already so morally bankrupt that they develop proprietary software, why would you trust them to always provide a “sustainable” service, be friendly to “open source” with discounts and publicity, and not to pull stunts on you like jacking up the price? It’s blind faith or nothing, and it’s a risk the Blender project need not take.

To quote @Ton, https://nitter.kavin.rocks/tonroosendaal/status/1003610646611709957?s=20&t=mdWhDgIyrZhl47fRZOIKuQ

FYI: Blender has its code on git (dot) blender (dot) org and developer services on developer (dot) blender (dot) org - we already host our own services since 2002.

(I had to edit the quote because apparently “new users can’t post more than two links”.)

Even if they have the choice, I don’t see it being a good usage the available resources to maintain this sort of project in the long run.

I agree, but this is irrelevant. The point is that this even being an option is an advantage they would not have had if it were proprietary.