2024-07-18 Triaging module meeting

Meetings
1

Triaging Module Meeting

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 2024-07-18T11:00:00Z. It is open for everybody interested to join the video call (link below).

Links

Attendees

Topics

  • number of untriaged reports is high (esp. following the 4.2 release), should take priority over everything else for the time being

  • Philipp has a week off from 29.07 through 03.08, does the team need additional help?

  • look for a way to include “Bug Fixes” in the release notes, gather ideas on how to do this best with minimal effort

  • followups from last meeting

  • recent important issues that are somehow hard to triage

    • if time permits, go over specific issues

Meeting Notes

  • 4.2

    • Lots of EEVEE crashes with older AMD cards > just ping devs/Richard :slight_smile: in the report if we cant repro

  • Philipp’s week OFF: decide if we want someone to help out with triaging while they are away. See if this decision can be made short term, if so, make this decision next week after seeing how the work load reduces as Blender 4.2 gets older.

  • Ideas for ways to include “Bug Fixes” from older releases in the release notes.

    • We would ideally want it to be automated. We discussed a few ideas. Further ideas are welcome.
      • Automatically check the “Working version” field of reports to see if the issue was introduce in the current version, or was in older versions (Most users don’t provide this information)
      • Automatically check the “Broken” field of reports to see if the issue was reported from a older version.
      • Filter reports attached to “fix” commits based on the date the report was made. We will miss reports for old versions made during the development of a new version.
      • Cherry picking fixes from new versions onto older versions and check for merge failures (Will not work in some cases, such as a bug fix after a refactor, or will give a false positive for a bug fix for a bug introduced in a different part of the code)
    • We could do manual work. But there is a high possibility for people to miss it.
      • Triagers add a label that denotes it is a bug from a older version.
      • Ask developers to add this information to their commit message?

  • Followups from last meeting

    • improve upon issues with unavailable hardware
      • Triaging module should create a list of hardware specific issues. Still pending. Philipp will start this.
    • Wizard
    • Feedback regarding our triaging infrastructure
    • Proposal to add more labels:
      • Proposal to add a “Release Show Stopper label” for bugs that need to be fixed before the next version. We will need to talk to Thomas about this as it primarily effects them.
        • This lead to another discussion around using milestones after a version has been released. Philipp will talk to Thomas about this as it primarily effects them.
    • Quality Project
      • Recap: Quality project did not go as well as expected.
      • Possibility of auto-changing the label back from “Needs Info from User” to “Needs Triage” if there is a response.
        • At the moment we have decided not to do that and would prefer to do things manually. Primarily because there can be some false positives.
      • Similar to Thomas’ daily high priortiy bug list: drop a list of “Needs info” reports in our Triaging channel?
        • If we really need a reminder, then we can go with a simple reminder like a weekly “Reminder: Check your ‘Needs info’ reports”. We can expand to something more technical if needed later on.
    • Bug reports on Extensions:
      • Get link to external issue tracker in the Blender UI (check with Campbell and Dalai)
      • Clarify if dev is responsible to check their issue tracker – related: get link gitea issue tracker in the Blender UI if dev opted out of providing the link (check with Campbell and Dalai)
      • Clarify rules of bug reporting (language etc. Add this to the Terms of Service?)
      • Philipp will double-check again

  • Other discussion

    • If there is a studio or creator using LTS, and it’s really important to them to have a LTS version that recieves regular bug fix updates, let Philipp know (would be nice to know how much of a “success story” LTS really is).

Following meeting

The following meeting will be on 2024-08-08T11:00:00Z. Again it will be open for everybody who’s interested.

7 Likes
2

I’ve written up a simple script that can roughly collect this information.

The general process is as follows:

  1. Get every commit with Fix # in it in blender-v4.2-release branch from the start of bcon1 until now. (Roughly 950 commits). This does miss commit messages like Fixes #, but these should be rare.
  2. Remove any of the Fix # commits that are also in blender-v4.1-release branch. (Down to roughly 650 commits)
  3. Check the report the the commit fixes and see if it meets the criteria for “Bug is from a older version”. The criteria are:
  • The report was made before the start of bcon1. This should be pretty reliable. And there’s roughly 70 commits that meet this criteria.
  • Or the report message doesn’t contain 4.2.0 or 4.2 in it. This could lead to some false positives (E.g. A report that doesn’t list the version number) and some false negatives (E.g. A report where something is broken in 4.1, but the person reported it from 4.2).
  1. Finally it can give you the list of commits. (Totaling 275)

I don’t know what the expected number of fixes would be, so I don’t know if this in the expected range or is too high/low. And as mentioned, there is the possibility of false positives and false negatives skewing the results.

Anyway, it’s a starting point.

2 Likes
3

Thx! I’ll compare this to a “manual” list and see how much that differs