Migration of libraries to Git LFS #108978

Open
opened 2023-06-14 15:28:47 +02:00 by Sergey Sharybin · 14 comments

This is a quick design task to communicate and coordinate transition of libraries from Subversion to Git LFS.

The are currently the following folders in the lib folder of Subversion:

  • asset_bundles
  • assets
  • benchmarks
  • darwin
  • darwin_arm64
  • linux_centos7_x86_64
  • linux_x86_64_glibc_228
  • packages
  • resources
  • tests
  • win64_vc15

Floating repositories

The following repositories are converted from Subversion to Git LFS, but not attached as submodules:

  • asset_bundles
  • packages
  • resources

Submodules

The remaining repositories are converted to Git LFS but also are attached to the blender.git as a submodule.

The main difference from out previous usage of submodules is that within this proposal the submodules are actually tracking a specific commit.

This leads to an extra steps when it comes to committing updates: the submodule has in the blender.git has to be updated after commit to a submodule, but on another hand, it allows to ensure libraries are tests are at their proper state when bisecting.

Directory layout

The following directory layout is proposed:

blender/
  * release/datafiles/
    * assets/        -> assets.git
      * publish/
      * ...
      * README.txt
  * lib/
    * darwin_x64/    -> lib_darwin_x64.git
    * darwin_arm64/  -> lib_darwin_arm64.git
    * linux_x64/     -> lib_linux_x64.git
    * windows_x64/   -> lib_windows_x64.git
  * tests/data/
    * benchmarks/    -> benchmarks.git
    * files/         -> test_files.git (renamed from svn/tests Subversion directory)

Saving disk space

It is undesirable that all checkouts of blender.git will checkout libraries for all platforms.

it seems to be possible to utilize the update submodule configuration.

From the local prototype the .gitmodules could look similar to this (note the update = none for the libraries):

[submodule "lib/linux"]
	update = none
	path = lib/linux
	url = ../lib_linux.git
[submodule "lib/windows"]
	update = none
	path = lib/windows
	url = ../lib_windows.git
[submodule "release/datafiles/assets"]
	path = release/datafiles/assets
	url = ../assets.git

With such configuration doing git submodule update will skip the libraries:

$ blender (main) % git submodule update
Skipping submodule 'lib/linux'
Skipping submodule 'lib/windows'
Cloning into '<DIR>/blender/release/datafiles/assets'...
done.
Submodule path 'release/datafiles/assets': checked out '<HASH>'

In order to make the libraries updated the following command (or similar to other platform) can be used: git config --local submodule."lib/linux".update checkout:

$ blender (main) % git config --local submodule."lib/linux".update checkout
$ blender (main) % git submodule update
Cloning into '<DIR>/blender/lib/linux'...
done.
Skipping submodule 'lib/windows'
Submodule path 'lib/linux': checked out '<HASH>'

Updating after commit to the submodule

When a commit is done to a submodule a parent repository (blender.git) needs to be updated as well.

The easiest workflow seems to be:

  • People who work on the content of the submodule commit to its repository from within the submodule directory.
    For example, if a new reference image is to be committed it is to be done from tests/data/files folders.
  • From the blender.git checkout:
    • git add <path/to/module>.
      For example, git add tests/data/files.
    • git commit and git push as usual

Update automation

For the make update will take care of the following things:

  • Ensure that the submodules are at the state at which the parent repository points to
  • Enables the libraries for the current platform (set the update to checkout)

Caveats

  • It is not possible to share libraries in a work-tree configuration.
    Which can actually be good in some cases, because it allows to have main and blender-v3.6.release branches to use their own libraries.
  • Commit to a submodule might need an extra care as the make update might put it to a detached head. A manual step to put it to a desired branch before commit might be needed.

Plan

  • Create for-now empty Git LFS repositories
  • Create configuration in the blender.git
  • Update the make update
  • Revoke commit access to Subversion from almost everyone (platform maintainers needs access to commit security fixes for LTS)
  • Remove Subversion configuration from buildbot
  • Commit content of Subversion to Git LFS
  • Switch CMake configuration to use submodule directories instead of Subversion
  • ...
  • Profit
This is a quick design task to communicate and coordinate transition of libraries from Subversion to Git LFS. The are currently the following folders in the `lib` folder of Subversion: * asset_bundles * assets * benchmarks * darwin * darwin_arm64 * linux_centos7_x86_64 * linux_x86_64_glibc_228 * packages * resources * tests * win64_vc15 # Floating repositories The following repositories are converted from Subversion to Git LFS, but not attached as submodules: * asset_bundles * packages * resources # Submodules The remaining repositories are converted to Git LFS but also are attached to the blender.git as a submodule. The main difference from out previous usage of submodules is that within this proposal the submodules are actually tracking a specific commit. This leads to an extra steps when it comes to committing updates: the submodule has in the `blender.git` has to be updated after commit to a submodule, but on another hand, it allows to ensure libraries are tests are at their proper state when bisecting. ## Directory layout The following directory layout is proposed: ``` blender/ * release/datafiles/ * assets/ -> assets.git * publish/ * ... * README.txt * lib/ * darwin_x64/ -> lib_darwin_x64.git * darwin_arm64/ -> lib_darwin_arm64.git * linux_x64/ -> lib_linux_x64.git * windows_x64/ -> lib_windows_x64.git * tests/data/ * benchmarks/ -> benchmarks.git * files/ -> test_files.git (renamed from svn/tests Subversion directory) ``` ## Saving disk space It is undesirable that all checkouts of `blender.git` will checkout libraries for all platforms. it seems to be possible to utilize the `update` submodule [configuration](https://git-scm.com/docs/gitmodules#Documentation/gitmodules.txt-submoduleltnamegtupdate). From the local prototype the `.gitmodules` could look similar to this (note the `update = none` for the libraries): ``` [submodule "lib/linux"] update = none path = lib/linux url = ../lib_linux.git [submodule "lib/windows"] update = none path = lib/windows url = ../lib_windows.git [submodule "release/datafiles/assets"] path = release/datafiles/assets url = ../assets.git ``` With such configuration doing `git submodule update` will skip the libraries: ``` $ blender (main) % git submodule update Skipping submodule 'lib/linux' Skipping submodule 'lib/windows' Cloning into '<DIR>/blender/release/datafiles/assets'... done. Submodule path 'release/datafiles/assets': checked out '<HASH>' ``` In order to make the libraries updated the following command (or similar to other platform) can be used: `git config --local submodule."lib/linux".update checkout`: ``` $ blender (main) % git config --local submodule."lib/linux".update checkout $ blender (main) % git submodule update Cloning into '<DIR>/blender/lib/linux'... done. Skipping submodule 'lib/windows' Submodule path 'lib/linux': checked out '<HASH>' ``` ## Updating after commit to the submodule When a commit is done to a submodule a parent repository (`blender.git`) needs to be updated as well. The easiest workflow seems to be: - People who work on the content of the submodule commit to its repository from within the submodule directory. For example, if a new reference image is to be committed it is to be done from `tests/data/files` folders. - From the `blender.git` checkout: - `git add <path/to/module>`. For example, `git add tests/data/files`. - `git commit` and `git push` as usual ## Update automation For the `make update` will take care of the following things: - Ensure that the submodules are at the state at which the parent repository points to - Enables the libraries for the current platform (set the `update` to `checkout`) ## Caveats - It is not possible to share libraries in a work-tree configuration. Which can actually be good in some cases, because it allows to have `main` and `blender-v3.6.release` branches to use their own libraries. - Commit to a submodule might need an extra care as the `make update` might put it to a detached head. A manual step to put it to a desired branch before commit might be needed. ## Plan - Create for-now empty Git LFS repositories - Create configuration in the `blender.git` - Update the `make update` - Revoke commit access to Subversion from almost everyone (platform maintainers needs access to commit security fixes for LTS) - Remove Subversion configuration from buildbot - Commit content of Subversion to Git LFS - Switch CMake configuration to use submodule directories instead of Subversion - ... - Profit
Sergey Sharybin added the
Type
Design
label 2023-06-14 15:28:47 +02:00

One issue this does not solve is that pull requests can't include new or updated test files, which means they can't be tested on the buildbot. A solution would be to store those files in the main Blender repository with LFS.

However using LFS for the main repository does imply that you can't easily switch git commits while offline. Through there must be ways to do it, by either downloading the entire history or skipping LFS updates somehow. Actually I guess the same problem exist when using libraries as submodules, that would also require internet access when switching to a commit with libraries changes. But those are updated less frequently.

It would be interesting to hear other's opinions on this. Personally I'd happily make this trade-off to be able to include tests in pull requests, but it's not a change to make lightly.

One issue this does not solve is that pull requests can't include new or updated test files, which means they can't be tested on the buildbot. A solution would be to store those files in the main Blender repository with LFS. However using LFS for the main repository does imply that you can't easily switch git commits while offline. Through there must be ways to do it, by either downloading the entire history or skipping LFS updates somehow. Actually I guess the same problem exist when using libraries as submodules, that would also require internet access when switching to a commit with libraries changes. But those are updated less frequently. It would be interesting to hear other's opinions on this. Personally I'd happily make this trade-off to be able to include tests in pull requests, but it's not a change to make lightly.

Also to summarize some of the advantages of this migration:

  • Get exact right library versions when switching between commits, for easy bisecting.
  • Ability to have repositories on Gitea, including history, references between commits and issues, auto closing issues, etc
  • Contribution to repositories like assets could go through pull requests.
  • Include tests changes in pull requests (if agreed).
  • Fewer tools to install and learn, only Git needed.
Also to summarize some of the advantages of this migration: * Get exact right library versions when switching between commits, for easy bisecting. * Ability to have repositories on Gitea, including history, references between commits and issues, auto closing issues, etc * Contribution to repositories like assets could go through pull requests. * Include tests changes in pull requests (if agreed). * Fewer tools to install and learn, only Git needed.
Member

I'm not experienced enough with git-lfs to make any worth while contribution to this discussion

I do have a concern this setup will break my current workflow, which is like this:

BlenderGit/
├─ Lib - symlink to any of the folders below/
├─ lib_main/  ( https://svn.blender.org/svnroot/bf-blender/trunk/lib ) 
│  ├─ win64_vc15
│  ├─ tests
├─ lib_293/  ( https://svn.blender.org/svnroot/bf-blender/tags/blender-2.93-release/lib/win64_vc15 ) 
│  ├─ win64_vc15
│  ├─ tests
├─ lib_330/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.3-release/lib/win64_vc15 )
│  ├─ win64_vc15
│  ├─ tests
├─ lib_340/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.4-release/lib/win64_vc15 )
│  ├─ win64_vc15
│  ├─ tests
├─ lib_350/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.5-release/lib/win64_vc15 )
│  ├─ win64_vc15
│  ├─ tests

I keep several releases checked out simultaneously in their own folders and symlink lib to what i need depending on the branch I am in, as I literally can't afford to wait an hour for the libs to download/update every time I switch a branch. I would get nothing done if i switch between the release branch and main a few times a day.

Additional todo: if we're going to have a significant amount of binaries in the source tree, the make source_archive/source_archive_complete likely needs some work to exclude these folders.

I'm not experienced enough with git-lfs to make any worth while contribution to this discussion I do have a concern this setup will break my current workflow, which is like this: ``` BlenderGit/ ├─ Lib - symlink to any of the folders below/ ├─ lib_main/ ( https://svn.blender.org/svnroot/bf-blender/trunk/lib ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_293/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-2.93-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_330/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.3-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_340/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.4-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ├─ lib_350/ ( https://svn.blender.org/svnroot/bf-blender/tags/blender-3.5-release/lib/win64_vc15 ) │ ├─ win64_vc15 │ ├─ tests ``` I keep several releases checked out simultaneously in their own folders and symlink `lib` to what i need depending on the branch I am in, as I literally can't afford to wait an hour for the libs to download/update every time I switch a branch. I would get nothing done if i switch between the release branch and main a few times a day. Additional todo: if we're going to have a significant amount of binaries in the source tree, the `make source_archive/source_archive_complete` likely needs some work to exclude these folders.

Two potential solutions to that problem:

  • Have multiple worktrees of the Blender repository. That way they can share the .git folder and any local branches and stashes, but still have different versions checked out.
  • Set the LIBDIR CMake variable to a different value for every build folder, and don't use the submodules.

We could of course not use submodules too, and instead do what we do for make update of addons but with a specified commit hash so somewhere. I'm not sure that's fundamentally different, but maybe there is some benefit to keeping this under more manual control rather than having git switch things for us.

Two potential solutions to that problem: * Have multiple worktrees of the Blender repository. That way they can share the .git folder and any local branches and stashes, but still have different versions checked out. * Set the `LIBDIR` CMake variable to a different value for every build folder, and don't use the submodules. We could of course not use submodules too, and instead do what we do for `make update` of addons but with a specified commit hash so somewhere. I'm not sure that's fundamentally different, but maybe there is some benefit to keeping this under more manual control rather than having git switch things for us.
Author
Owner

@LazyDodo I guess you already not relying on the make update, otherwise it will "ruin" the SVN checkout which symlink is pointing to. If that's true, I think there is a third option:

  • Keep the windows's libraries submodule at update = none (which is the default), and make it lib/windows_x64 be a symlink to one of git-lfs checkouts done somewhere else. Not sure what git status performed in the parent repository will tell you in this case though :)
@LazyDodo I guess you already not relying on the `make update`, otherwise it will "ruin" the SVN checkout which symlink is pointing to. If that's true, I think there is a third option: * Keep the windows's libraries submodule at `update = none` (which is the default), and make it `lib/windows_x64` be a symlink to one of git-lfs checkouts done somewhere else. Not sure what `git status` performed in the parent repository will tell you in this case though :)
Member

I have to admit, i'm not married to my workflow, as long as I can quickly (< 5 mins) switch libs I'm fine, HDD space and bandwidth are essentially infinite these days my time however is not. That being said, users on metered connections will likely not share that sentiment.

I have to admit, i'm not married to my workflow, as long as I can quickly (< 5 mins) switch libs I'm fine, HDD space and bandwidth are essentially infinite these days my time however is not. That being said, users on metered connections will likely not share that sentiment.
Author
Owner

Started the Blender-side changes needed to implement the proposal: #117946

There are a couple of things which can not easily be submitted as PR:

  • Conversion of libraries from SVN to Git-LFS
  • Initialization of submodules

Attached scripts which I used locally to perform those steps.

The SVN to Git-LFS conversion is done taking the following things in mind:

  • Only 3.3, 3.6 and trunk are converted. Those are the only tracks which are still active
  • The repository name is more closely aligned with platform/architecture naming used by release names
  • Linux libraries are merged from two directories to a single repository with several branches
  • Branch names are aligned to the ones used in Git (blender-v*-release)

For the next steps:

  • Port 4.1 libraries to corresponding branches in the SVN->Git conversion
  • Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons?
  • Do we want assets to be a real Git submodule, or we handle it as add-ons as well?
  • We'll need to have some down-time from libraries update, finalize SVN->Git migration, and then finalize the code-side changes, including ensuring CI/CD works fine
Started the Blender-side changes needed to implement the proposal: #117946 There are a couple of things which can not easily be submitted as PR: - Conversion of libraries from SVN to Git-LFS - Initialization of submodules Attached scripts which I used locally to perform those steps. The SVN to Git-LFS conversion is done taking the following things in mind: - Only 3.3, 3.6 and trunk are converted. Those are the only tracks which are still active - The repository name is more closely aligned with platform/architecture naming used by release names - Linux libraries are merged from two directories to a single repository with several branches - Branch names are aligned to the ones used in Git (blender-v*-release) For the next steps: - Port 4.1 libraries to corresponding branches in the SVN->Git conversion - Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons? - Do we want assets to be a real Git submodule, or we handle it as add-ons as well? - We'll need to have some down-time from libraries update, finalize SVN->Git migration, and then finalize the code-side changes, including ensuring CI/CD works fine

The repository names use underscores, but we use dashes for existing repositories. I think we should be consistent.

We also use the blender- prefix usually, but I can see the motivation for leaving it our here as it's a bit redundant with the organization and the libs are used by Cycles standalone. Maybe some would still benefit from the prefix, like blender-test-data.git and blender-assets.git?

Maybe the tests directory structure could be a bit flatter for convenience?

  • tests/data -> blender-test-data.git
  • tests/benchmarks -> benchmarks.git

For these others we could consider:

  • asset_bundles -> asset-bundles.git
  • packages -> lib-source.git
  • resources: put the single icon_geom in assets.git?
The repository names use underscores, but we use dashes for existing repositories. I think we should be consistent. We also use the `blender-` prefix usually, but I can see the motivation for leaving it our here as it's a bit redundant with the organization and the libs are used by Cycles standalone. Maybe some would still benefit from the prefix, like `blender-test-data.git` and `blender-assets.git`? Maybe the tests directory structure could be a bit flatter for convenience? * `tests/data` -> `blender-test-data.git` * `tests/benchmarks` -> `benchmarks.git` For these others we could consider: * asset_bundles -> `asset-bundles.git` * packages -> `lib-source.git` * resources: put the single `icon_geom` in `assets.git`?
Author
Owner

Replacing underscore with dash shouldn't be a bit of a deal.
Could be a bit weird though: lib-windows-x64 ?

The tests directory can indeed become flatter.

I've put the scripts to the PR now.
We can also sit together, and do the adjustments. Will be faster than bouncing comments.

Replacing underscore with dash shouldn't be a bit of a deal. Could be a bit weird though: `lib-windows-x64` ? The tests directory can indeed become flatter. I've put the scripts to the PR now. We can also sit together, and do the adjustments. Will be faster than bouncing comments.
Member

While windows libs have been ABI stable ever since vs2015, there is no guarantee it will stay this way, lib-windows-x64 may be too generic? on the other hand, it hasn't broken in 9 years, we could just cross that bridge when we get there...

While windows libs have been ABI stable ever since vs2015, there is no guarantee it will stay this way, `lib-windows-x64` may be too generic? on the other hand, it hasn't broken in 9 years, we could just cross that bridge when we get there...
Author
Owner

@LazyDodo For that I though it will be easier and flexible to use branches. Similar to how eventually a newer glibc ABI will replace Linux libraries.

@LazyDodo For that I though it will be easier and flexible to use branches. Similar to how eventually a newer glibc ABI will replace Linux libraries.

For the ABI, I guess the question is if we ever want to support two ABIs and two sets of libraries at the same time. Probably best to deal with that if it becomes a problem.

For the underscores vs dashes, I forgot to mention that we probably want to keep the folder name with underscore for consistency, just the repo name would use dashes I think. The repo name for libs could also be e.g. lib-window_x64.

For the next steps:

  • Port 4.1 libraries to corresponding branches in the SVN->Git conversion
  • Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons?
  • Do we want assets to be a real Git submodule, or we handle it as add-ons as well?

I'm not immediately sure. Currently I don't think we care about these being tightly connected to any particular Git revision, so not having them as a submodule seems most convenient.

Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them. So maybe the asset should be connected, but the benchmarks not? It would be a bit less convenient that a Blender developer would have to do something when studio artists update these. But I guess it's justified.

For the ABI, I guess the question is if we ever want to support two ABIs and two sets of libraries at the same time. Probably best to deal with that if it becomes a problem. For the underscores vs dashes, I forgot to mention that we probably want to keep the folder name with underscore for consistency, just the repo name would use dashes I think. The repo name for libs could also be e.g. `lib-window_x64`. > For the next steps: > - Port 4.1 libraries to corresponding branches in the SVN->Git conversion > - Need to agree on how to handle benchmark repository. Do we want it to ever be connected to Git repository, do we handle it similar to how we do it with add-ons? > - Do we want assets to be a real Git submodule, or we handle it as add-ons as well? I'm not immediately sure. Currently I don't think we care about these being tightly connected to any particular Git revision, so not having them as a submodule seems most convenient. Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them. So maybe the asset should be connected, but the benchmarks not? It would be a bit less convenient that a Blender developer would have to do something when studio artists update these. But I guess it's justified.
Author
Owner

The repo name for libs could also be e.g. lib-window_x64

Sounds good to me. Can also think of it as an alternative to "lib/windows_x64". Not sure it is important or just me seeing patters :)

Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them.

Or when some node group becomes incompatible with some Blender version, having stronger coupling seems to reduce risk of things getting out of sync.
Unfortunately, it seems that we'd better spent a bit more educated guess now, as changing between "floating module" and git-submodule is not impossible, but is disruptive, especially for bisect.
Perhaps we can have a quick talk with Dalai, Julien, and Simon and see if they feel strongly about having them "floating".

For the benchmarks, it seems easiest to keep it "floating". Will save us from fitting it into the make_update.py, we'd just need to git-ignore, and then it will be manual checkout for the initial svn->git switch, and then we can add it to the helper scripts. Kinda to scope things a bit more narrow.

One thing I don't really understand, is whether we need to do anything with the asset_bundles:

  • Can we just get the latest snapshot of all active tracks/branches, or do we need full history?
  • Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check

Ah, one more thing I forgot to mention: we'd need to set-up permissions on the repositories. Is easy, but we should not forget about it :)

> The repo name for libs could also be e.g. `lib-window_x64` Sounds good to me. Can also think of it as an alternative to "lib/windows_x64". Not sure it is important or just me seeing patters :) > Though I can imagine that happening for the asset one in the future, if we rely more on shipping with node groups and testing them. Or when some node group becomes incompatible with some Blender version, having stronger coupling seems to reduce risk of things getting out of sync. Unfortunately, it seems that we'd better spent a bit more educated guess now, as changing between "floating module" and git-submodule is not impossible, but is disruptive, especially for bisect. Perhaps we can have a quick talk with Dalai, Julien, and Simon and see if they feel strongly about having them "floating". For the benchmarks, it seems easiest to keep it "floating". Will save us from fitting it into the `make_update.py`, we'd just need to git-ignore, and then it will be manual checkout for the initial svn->git switch, and then we can add it to the helper scripts. Kinda to scope things a bit more narrow. One thing I don't really understand, is whether we need to do anything with the `asset_bundles`: - Can we just get the latest snapshot of all active tracks/branches, or do we need full history? - Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check Ah, one more thing I forgot to mention: we'd need to set-up permissions on the repositories. Is easy, but we should not forget about it :)

One thing I don't really understand, is whether we need to do anything with the asset_bundles:

  • Can we just get the latest snapshot of all active tracks/branches, or do we need full history?
  • Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check

As far as I know it's just files that are available for download here, and not connected to Blender build and packaging.
https://www.blender.org/download/demo-files/

Once the extensions website is online, these assets should become available there. So maybe it's a more a general question, if we have any officially maintained asset extensions, where do we put the Git repository?

Since it's effectively done by the Blender Studio right now, maybe it belongs in the studio/ organization?

> One thing I don't really understand, is whether we need to do anything with the `asset_bundles`: > - Can we just get the latest snapshot of all active tracks/branches, or do we need full history? > - Is it connected in any way to the blender build/packing process? I didn't see anything about it, but want to double-check As far as I know it's just files that are available for download here, and not connected to Blender build and packaging. https://www.blender.org/download/demo-files/ Once the extensions website is online, these assets should become available there. So maybe it's a more a general question, if we have any officially maintained asset extensions, where do we put the Git repository? Since it's effectively done by the Blender Studio right now, maybe it belongs in the `studio/` organization?
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#108978
No description provided.