2025-01-09 Triaging module meeting

[lichtwerk]

Biweekly Triaging module meeting for planning and coordination.
Folks on the payroll should attend if possible, others are invited as well.
In these meetings, we can keep us up-to-date on everything triaging, discuss recent important issues and see if we can bring the module forward.
I believe it is also good to see human faces once in a while :), so there is always room for some personal stuff if appropriate.

The meeting will be on 2025-01-09T12:00:00Z. It is open for everybody interested to join the video call (link below).

Links

• Video call google meet for now, we can try jitsi as well if people prefer
• #module-triaging matrix chat room on chat.blender.org
• #module-triaging matrix chat room link for other matrix clients
• live meeting notes

Attendees

• @lichtwerk
• @PratikPB2125
• @ChengduLittleA
• @Alaska

Topics

• Announcements

  • any?

• 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
    • PR is in review #131615 - Release tools: Add script to generate a list of bugs fixed from last release - blender - Blender Projects
  • Feedback regarding our triaging infrastructure
    • news?
  • Wizard
    • Gather a list of two or three examples from “out there” that work similar to what we want to achieve (add that to #78 - Gitea: Triaging Wizard - blender-projects-platform - Blender Projects) is still pending, some more discussion in #121260 - Issue template design discussion - blender - Blender Projects 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?
    • There has been progress on the crash window pull request
  • Proposal to add “Crash” / “Regression” labels
    • We asked Sean if they still wanted these labels. They said they would think about it and get back to us at a later date.
    • If Sean decides they want these labels, then we’d ask for input form other developer’s and make a decision then.
  • discussion about exposing dependency cycles to the end user (an idea we have discussed in previous meetings)
    • Yimming will discuss exposing dependency cycles in the UI with other developers and create a design task for it.

Meeting Notes

• Ideas for ways to include “Bug Fixes” from older releases in the release notes
  • PR is in review #131615 - Release tools: Add script to generate a list of bugs fixed from last release - blender - Blender Projects
    • Alaska updated it based on the formatting changes requested by Campbell.
    • Philipp will double check it still works the way they want.
    • Then we need to wait for general review from Campbell.
• Discussion about Tests:
  • Are docs sufficient for any dev to add a test in lets say 30mins?
  • Which scenarios are complicated/hard adding tests for?
    • some are easier (e.g. Cycles – just add a .blend, generate the expected output image, commit those)
    • we have mesh equality API, but not for other types
    • UI (mouse input possible? Simulate operators needing mouse input)
    • @lichtwerk intends to add more tests and will go over the workflow trying to suggest ways to improve
• followup on the VR report with Jeroen

Following meeting

The following meeting will be on 2025-01-23T12:00:00Z. Again it will be open for everybody who’s interested.

[Sean-Kim]

@lichtwerk

• Are docs sufficient for any dev to add a test in lets say 30mins?
• Which scenarios are complicated/hard adding tests for?
  • some are easier (e.g. Cycles – just add a .blend, generate the expected output image, commit those)
  • we have mesh equality API, but not for other types
  • UI (mouse input possible? Simulate operators needing mouse input)
  • @lichtwerk intends to add more tests and will go over the workflow trying to suggest ways to improve

Just some thoughts in this area from recently working on testing:

• Rendering tests - The docs were pretty helpful; but figuring out what, if any guidelines we should follow with the files was a bit difficult (e.g. Is there a filesize we recommend for the .blend file?). I still haven’t committed the changes I’m planning on doing for sculpting, but I’d like to use it for a more broad type of test for comparing strokes visually. Hope to share some progress here in the coming week or so.
• UI Tests - This has come up a few times recently, @deadpin did work here a few weeks back experimenting with this PR for some sculpt tests; though using it was apparently rather difficult though for things that don’t have keybinds or need specific positioning. There was a discussion in the EEVEE & Viewport channel about this too. The general gist is that getting it automated on the buildbots needs this platform issue, but having something that works locally is currently possible. In what little experimentation I did that worked off of this, I found the API to be a bit difficult to use.
• C++ tests - Varies in difficulty based on how “pure” of a function it is. I’ve found setting up the test state to be the most difficult part. There’s some new docs here about a simple example of setting this up, and I have a more complex example in the works that also hopefully gets added next week.

To answer the general question of “how feasible is it to add a test within 30 minutes”, I think the main hurdle is if a similar enough example for a given test exists in the codebase. More documentation is of course good, but I think when nothing similar seems to exist is when it quickly becomes daunting to figure out.