Sybren is handing over Linux platform maintainer role to Campbell. Sergey will help Campbell get started.
Python Module
Since the last admin meeting the bpy module has seen many improvements.
The question now is if we want to officially maintain this on pypi.org. There is agreement that this is useful, but it’s lower priority than some other priorities for devops like Gitea migration, so might be some time until the required buildbot automation for this is added. Manual uploads for Linux until that automation is in place could happen.
We are in the process of getting the package ownership transferred to the Blender Foundation.
Security Policy
Campbell will soon add the wiki page regarding reporting Blender security vulnerabilities. The [email protected] email was set up already.
Ray Molenkamp added a tool for testing for CVEs in library dependencies. The process to check this regularly and how to respond to vulnerabilities of different severities or different levels of actual impact on Blender is still to be worked out.
Arnd proposes checking mailing list like those of Debian, as they usually provide good analysis of CVEs and their impact that we can also use for Blender.
Arnd proposed to look into a plan for CVE handling, will discuss with Brecht some more details of this.
Release Process
The release process has gotten more complicated, with more steps and people involved than before. There was discussion regarding how to simplify this, which steps can be removed or need to be added.
Generally the responsibility on release day is to test ensure that the code gets delivered correctly as it exists in the release branch. That is, the package got delivered on download.blender.org and in the various stores correctly. Any tests to see if functionality works correctly should be either automated or done when committing/backporting bugfixes, rather than doing a somewhat arbitrary set of manual tests on release day.
When backporting bugfixes, we should be more careful to check that the backport worked correctly. When in doubt, test the fix using the report or ask the developer involved to backport and test it.
Bugfixes should be in master for at least a week before backporting to LTS, to ensure they have been tested, as Jeroen was doing before. Backports should be in the release branch by Friday before the LTS release next Wednesday.
For the next LTS, we should not immediately create a new Windows store product on the day of the release, but rather when the next release comes out as we had done before. Updating multiple products involves some complications in MSIX packaging that we want to avoid.
LTS releases should be done once a month, even if there is just one (high priority) bugfix. The process should be fast enough to accommodate this. Ideally a single person should be able to handle it, with another developer around to help out if needed. The changes mentioned above should at least get us closer to this, even if there are still some practical reasons why we might want to have multiple peopling helping out.
Thomas and Philipp will update the release process wiki doc to document this and complete other missing information.