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

Links

Attendees

Topics

  • followups from last meeting

    • number of untriaged reports
      • news?
    • “most” crashes should be high priority
      • news?
    • improve upon issues with unavailable hardware
      • news?
    • feedback regarding our triaging infrastructure
      • TODO: design task for wizard
      • IDEA (Iliya Katushenock): Usage of certain tokens (not bug/error/issue but crash/locking/exception?) in the title of the report
      • IDEA (Iliya Katushenock): Do not write titles on more than one line
      • IDEA (Iliya Katushenock): implementing a blender-bisect for the user (using Blender Builds - blender.org)
    • feedback regarding triaging metrics
      • news?
    • first round PR review
      • news?
    • automated crash reporting
      • news?
    • copyrighted material in user repos
      • news?

  • recent important issues that are somehow hard to triage

    • if time permits, go over specific issues

Meeting Notes

Will move taking notes to https://hackmd.io/ for next meeting (next to obviously being more collaborative, this will also prevent what happened this time : Philipp had a hard crash during the meeting and lost taken notes unfortunately)

  • followups from last meeting

    • number of untriaged reports is still a bit high, goal is to half the number the coming weeks

    • setting High priority on crashers has been mostly greenlit by modules (they will take care of lowering again if appropriate)

    • improve upon issues with unavailable hardware

    • feedback regarding our triaging infrastructure

      • gitea issues
      • bug reporting wizard
        • content-related : which “questions” to ask? (e.g. crash/locking/exception/unexpected behavior and continue from there), which things to prevent the user from putting in the reports?
        • tech-related : could be gitea-native, webbased (but separate from gitea), local executable or even blender-native (e.g. via Addon or making the reporting operator more sophisticated)
        • incorporate a “user bisect”?, narrowing down the time something broke by checking daily builds from Blender Builds - blender.org
        • Germano offers to set up Addon prototype
        • idea has the risk of getting bloated >> set up a design task on gitea for this to discuss further
      • labels / issue titles / commit messages
        • changing title “to give a more precise description” is vague, can lead to very long titles, can have redundancy with labels, but all of this is still better than leaving the title vague… examples where discussed [which was already helpful], no hard DOs or DONTs
        • labels (at least the interest labels) could be more fine-grained [also helps with the above], approach corresponding modules with suggestions
      • some gitea requests still:
      • automated crash reporting
        • Philipp still has to followup on this to express general interest in this

    • feedback regarding triaging metrics

      • Thomas has investigated related code [no working code yet though], still decide whether to add this to graphana or elsewhere

    • first round PR review

      • some discussion about the scope this should have (formatting, general code guidelines, if it still builds, if functionality is expected, or even comment on design?). This all depends on the level of experience regarding the code are in question, so no hard DOs or DONTs

    • copyrighted material in user repos

  • Thomas suggests to go over old reports (checking if they are still valid)

    • Philipp questions the usefulness of Needs Info from Developers status
    • Philipp reminds that this is Module (not Triaging) responsibility
    • agreement though that this is beneficial for the blender project and Triaging will join efforts
    • Thomas will reach out to Modules as well

  • recent important issues that are somehow hard to triage

    • after 135min meeting time, it was decided to not start going into details about specific reports
    • for next meeting, the plan is to have time reserved for this

Following meeting

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

8 Likes
2

does it mean that a regular user will be able to detect when a bug was introduced? :thinking:

3

I wasn’t at the meeting during that discussion so there may be more information to this.

But if a Blender-bisect using achieved builds gets implemented, then a user can figure out the time frame a bug was introduce (E.G. It was introduced between commit A on Monday and commit B on Wednesday last week).

A user can already do this if they want, but I believe the proposed idea was to make it easier to understand and access for the average user.

If a user wanted to figure out exactly which commit caused an issue, then we’d either have to setup a system to build Blender on their computer (Extremely unlikely to happen), setup a system to do compilation for this investigation on the build bot (probably not a good idea), or the Blender build bot would have to create a release build for every commit made, which I don’t think will happen.

2 Likes
4

We’ve discussed this a little bit on Blender chat. I just wanted to add some extra ideas here.

Could hardware list be broken up into modules? For example, you have one webpage, and on that webpage there is one table per module listing the people, their tags on Gitea, and their hardware.

I bring this up because triagers are likely to go there to find someone with the hardware to test a platform specific issue. And I believe the process should be like this to avoid bringing unrelated people into bug testing whenever possible:

  • Does a module triaging team member have the hardware?
  • No, does a volunteer triager have the hardware? (This requires volunteers to be in a separate table)
  • No, does a developer in the effected area (E.G. Module EEVEE for a EEVEE bug) have the hardware?
  • No, does any developer have the hardware?

And breaking up people/hardware based on module could help with this work flow.

There’s also the discussion of how do you contact the person with the hardware? Contact them on Blender chat? Or tag them to take a look at the issue on Gitea? I prefer tagging on Gitea.

One of the topics discussed was about adding the impacted area to the title. For example, if a user experiences a issue in Cycles, their report would be named Cycles: REST OF TITLE.

I believe the general consensus was that this wasn’t needed, because the Cycles developers would already know it was a Cycles issue because it was added to the Cycles module.

However, there are other situations. For example, if a user reports a bug about Cycles, and it’s limited to HIP, then HIP: REST OF TITLE or some other layout (E.G. X Material renders incorrectly in HIP) may also be good. Other examples are FBX: REST OF TITLE for a FBX issue that’s sent to the IO module. Or EEVEE-Next: REST OF TITLE for a EEVEE-Next issue sent to the EEVEE module.

I didn’t get to share my thoughts on this in the meeting (I didn’t have a microphone). But there’s a few questions for this that we may be able to decide upon here or in Blender Chat, or it may need a spot in a future meeting.

Is titling a report FBX: REST OF TITLE useful? Or should interests be made for things like FBX, OBJ, STL, HIP, CUDA, etc? This is something that should be discussed with module owners and the triaging team on which they prefer, or if this is even something that needs adjusting.

1 Like
5

The hardware page is back at https://developer.blender.org/docs/handbook/bug_reports/hardware_list/ now

Additional module information could help, yes (the order you mentioned in which to ping people makes sense to me).
Page is not pretty already due to line wrapping, so an additional column might decrease readability even further though, will try it out.

We could link to the gitea profile, yes.

Agree here to figure this out with the corresponding modules.

6

I was thinking of something like this:

Example of multiple tables
Example of multiple tables1182Ă—1328 85.3 KB

2 Likes