We migrated to the new projects.blender.org platform. The general information is in this blog post. Here is additional information for developers (this list can be updated as more is found).
Labels and Project Boards
A few important things to understand for module owners and the triaging team:
- Bug triaging will assign labels to reports. Type, status, priority and module must be set for a report to be considered fully triaged. The triaging team should not assign issues to project boards. See the bug triaging docs for details.
- It is up to every module how they want to organize their board, or even use multiple boards. We recommend to put only to do and design issues on the project board, and perhaps a few bug reports if they are part of a specific planning.
- Each project board will have links to a query for classified and unclassified bug reports.
- Assign every non-WIP pull request to a relevant project board, so it gets seen by the relevant developers.
Help Needed from Modules
- One empty project board has been created per module. Design and to do issues need to be added to the board, which can be done with batch editing in the issue list. The old workboards are available on the archived ro.developer.blender.org for reference.
- Note that an issue can only be placed on a single project board, while it may currently be part of multiple workboards on ro.developer.blender.org. You will need to decide what goes where in such cases.
- Old project tags have been migrated as labels with a legacy prefix. If you prefer to continue using a legacy label, check that they are assigned to the right issues and then rename the label. To name a label to indicate relevance to a project or module, use the
interest/
prefix. After a while the remaining legacy labels will be removed. Wait a bit with removing any labels until the triaging team has checked it’s safe to remove them. - Each module gets a wiki page on the blender repository. This replaces the old project description page. Please update your page to fix broken links and make it well formatted.
- If you used parent and child tasks, those relations will have to be manually recreated.
Commits, Issues & Pull Requests references
By default, commits can be referenced by their git hash (9fecf1f8b8
), and similarly for issues and pull requests using their uid (#93407
).
However, this will only work properly for references to items within a same organization/repository.
Commits from another repository can be referenced by pre-fixing the organization/repository
‘path’, and using an @
instead of the #
: blender/blender@9fecf1f8b8
Issues and pull requests from another repository can be referenced by pre-fixing the organization/repository
‘path’: blender/blender#93407
Wiki Templates
Templates to reference commits, issues etc. on https://wiki.blender.org have been updated.
{{GitCommit|}}
has been updated, with a new, future-proof recommended syntax:{{GitCommit|1234567890|flamenco|studio}}
{{Issue|}}
replaces the old{{BugReport|}}
.{{PullRequest|}}
replaces the old{{PhabDiff|}}
.
These three new templates follow the same parameter logic: uid|repository|organization_or_fork
, the last two being optional and defaulting to blender/blender
.
blender-bot
There is an automated bot to start builds, keep closed and open issues status valid, and add information to commits about the issues, pull requests and other commits referencing them. More information here:
Subversion
The subversion repositories cannot be browsed from projects.blender.org, but remain active with plans to migrate them to git-lfs.
For committing to svn repositories, you must generate an application token to use as your password.
Differences with Phabricator
- Subscription to issues are controlled by the users themselves and not visible to others. @ mentions will not subscribe others, they will get an email and notification, and can then choose to subscribe. @ mentions autocomplete only includes participants in the issue and members of a team in the blender organization.
- Changing issue labels, projects and milestones does not send notifications or emails. So also leave a comment if others need to be notified.
- If you want to get emails for your own actions, there is an option for that in the email account settings.
- Gitea does not currently remember unsubmitted comments when closing issues or pull requests. Be sure to save them somewhere if you want to continue later.
- Merging duplicate issues is not natively supported currently. You have to manually close the issue, and write a comment like this: “Merged into #123. Please subscribe there if you want to see further updates”.
- You can place pull requests on a project board.
- The command line tool for Gitea is tea. This is more of an optional thing than arc, pull requests work fine without it.
- If you made commits with another email address than your Blender ID, you can add additional email addresses in the account settings to have them recognized as yours.