## Attendees

* @lichtwerk
* @Alaska
* @ChengduLittleA
* @modmoderVAAAA
* @Arman_Singh_Kshatri

## Topics

* Announcements
* @Sean-Kim proposes to add "Crash" / "Regression" labels for the benefit of better organizing their work.
* Keep an eye on the [Quality Project](https://projects.blender.org/blender/blender/issues/130670)

* Pending TODOs/followups (wont get an active topic if no news have to be announced)
* Have meetings consistently every two weeks (no matter Philipps availability), no conclusion on how to organize this yet
* Ideas for ways to include "Bug Fixes" from older releases in the release notes
* Thx to @Alaska [script](https://projects.blender.org/Alaska/collect_release_fixes) and some manual work from the triaging team correcting "Worked" and "Broken" fields on many issues that had fix commits, we were able to pull of a [list for the 4.3 release](https://developer.blender.org/docs/release_notes/4.3/bugfixes/)
* Planned to do for every release now, friendly reminder to always set "Worked" and "Broken" fields (including checking active LTS releases) while doing triaging already
* Feedback regarding our triaging infrastructure
* [126039](https://projects.blender.org/blender/blender/pulls/126039) landed
* Wizard
* Gather a list of two or three examples from "out there" that work similar to what we want to achieve (add that to https://projects.blender.org/infrastructure/blender-projects-platform/issues/78) is still pending, some more discussion in https://projects.blender.org/blender/blender/issues/121260 though regarding Richards experiments
* Could we add a feature that lets users know the location of crash logs after Blender crashes so they can more easily provide it in a bug report?
* Design task in https://projects.blender.org/blender/blender/issues/128621, needs further input
* [WIP PR](https://projects.blender.org/blender/blender/pulls/129974)

## Meeting Notes

* @Sean-Kim proposes to add "Crash" / "Regression" labels for the benefit of better organizing their work. This is primarily for tasks that were marked as high severity due to them being crashing and regression, but then lowered to normal, but still need to be tracked as they're kind of bad.
* Philipp is concerned that we'll have these labels, but they aren't applied consistently, making them less useful as a sorting tool.
* Yimming is concerned that all the old reports won't have this tag unless we go through them again.
* Alaska was concerned that if a regression isn't fixed by the next release, the regression label will start to lose relevance.
* Yimming proposed the idea of removing the normal severity tag and replace it with "Crash", "Regression", "Performance", etc tags.
* This has a similar issue that all the old reports aren't sorted.
* Ilya was concerned that going with this approach could result in us requiring many labels to properly sort it.
* Should it be possible to lower a crash from high severity to normal?
* Yimming said there could be situations where this is desired, such as crashes in systems that need large refactors to avoid cases where crashes occur.
* At the moment only Sean has raised this idea with us. We should discuss with other modules/developers if they also want this and it can influence our decision making on this.
* We have made no conclusions a the current point in time. We can continue discussion in Blender chat, with other developers, and in future meetings.
* Keep an eye on the [Quality Project](https://projects.blender.org/blender/blender/issues/130670)
* As triagers we see lots of reports. We may be able to provide pointers towards modules on what is commonly reported to help guide what they focus on.
* Generally modules will have their own ideas on what to do. But if they can approach us for this information.

* Pending TODOs/followups (wont get an active topic if no news have to be announced)
* Ideas for ways to include "Bug Fixes" from older releases in the release notes.
* We developed a [script](https://projects.blender.org/Alaska/collect_release_fixes) to assist with this, sorted some commits, and add a list of bug fixes to the [4.3 release notes](https://developer.blender.org/docs/release_notes/4.3/bugfixes/).
* To assist the script for future releases, we are encouraged to fill out the broken and working fields accurately. We are also encouraged to check:
* The current release, previous release, and all active LTS releases to fill out this information accurately. This can also help with figuring out what should be backported to LTS releases.
* The next step is to get the script into the Blender repository. Alaska will make a few minor adjustments and open a pull request for this.
* To reduce stress close to release manually sorting commits that didn't have the right information, we may run the script on a weekly or bi-weekly basis.
* Yiming brought up discussion about exposing dependency cycles to the end user (an idea we have discussed in previous meetings).
* Could we add a editor that shows this information to users?
* Expand the info editor to include useful information for users?
* Add a flashing warning at the bottom of the Blender UI when a dependency cycles is created/found?
* Related to the dependency cycle discussion, there was discussion about mesh validation tools.
* Campbell has proposed the idea of running mesh validation tools on file load.