Triaging Module Meeting
First (then 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-15T12: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 chat channel
Attendees
- Germano Cavalcante @mano-wii
- Iliya Katushenock @modmoderVAAAA
- Jesse Yurkovich @deadpin
- Philipp Oeser @lichtwerk
- Pratik Borhade @PratikPB2125
- Thomas Dinges @ThomasDinges
Topics
-
improve upon issues with unavailable hardware
- can this be virtualized in some way? Using some sort of (online) service?
- this mainly has overlap with the #eevee-viewport-module , would it be possible to access their hardware in some way?
-
feedback regarding our triaging infrastructure
- are we still missing functionality on the gitea side?
- are we missing tools that could make our lives easier, see e.g. this PR
- whishlist for @mano-wii 's AI firefox/chrome extensions? can we set up a server for them? how about a custom trained LLM?
- is there interest in automated crash reporting (has been worked on before, but unfinished, especially on the server side: Blender Archive - developer.blender.org)
-
feedback regarding triaging metrics
- can we improve upon the metrics
- what are people interested in?
- what can we learn from them for our workflow?
- can we act as a “red alert” if a particular module has (unexpectedly) high number of reports?
-
first round PR review
- do we have capacities to be more engaged here? what are the experiences so far?
-
recent important issues that are somehow hard to triage
- get issues out of the triaging queue that are somewhat “stuck”
Meeting Notes
-
announcements before going int topics
- number of untriaged reports is a bit atm., goal is to half this until next meeting
- “most” crashes should be high priority
- A clearer definition of “most” is needed (exceptions might be EOL features, some areas of the py API, …)
- Philipp will go over older crash reports
-
improve upon issues with unavailable hardware:
- no clear solution yet, Philipp will reach out to HQ to determine if hardware access can be improved
- the solution that works for now: reach out to the community
-
recent important issues that are somehow hard to triage
- this time we have not gone over specific issues (but the following meetings will have space for exactly this)
- continue to use chat to reach out early to other triagers if in doubt
- arch linux has unconventional builds (maintainer is responsive though), ask reporters to try official releases / buildbot builds first
-
feedback regarding our triaging infrastructure
- some gitea requests still (make sure these are reported to the right places):
- “bug”: subscriptions, filter by tag > 2nd page resets filters
- “request” : improved filtering still (e.g. by dates)
- “request” : be more restrictive to improve report quality
- required fields that cannot be omitted (e.g. blender version)
- check again on a “wizard” that takes you through a couple of questions (TODO for triaging: need to come up with a “question-tree” then)
- “request” : references “bundled” in a sidebar of issues (so you dont have to scroll the whole page)
- “request” : PRs “bundled” in a sidebar of issues (so you dont have to scroll the whole page)
- “request” : make duplicates distinctive (not only references)
- “request” : move reports across repos (blender >> addons or vice versa, also documentation)
- “request” : remove user rights to assign projects (should be using labels anyways)
- “request” : remove user rights to reopen (debatable)
- “bug” : reopening: does not restore labels correctly
- some gitea requests still (make sure these are reported to the right places):
-
automated crash reporting
- interested, needs some more info on details (@lichtwerk will followup on this)
- are “same” crashes automatically deduplicated?
- how much more work required to have this finished?
- discuss (with HQ) consequences of blender sending information / accessing the internet (introduction of extensions platform might be a good time to do this though), possibility to opt out
- interested, needs some more info on details (@lichtwerk will followup on this)
-
@mano-wii 's AI firefox/chrome extensions
- Germano gave a presentation of the current state
- triage HUB a priority (compared to e.g. training a full OSS LLM)
- no “official” support from blender (unless fully OSS at some point)
-
triaging metrics
- split these existing metrics “by module” (this would already give a good measure of where to raise an alert flag), @ThomasDinges will look into it
-
first round PR review
- already happening (and growing)
-
copyrighted material in user repos
- check on the right way to react if this gets uploaded , @lichtwerk will check
Following meeting
The following meeting will be on 2024-02-29T12:00:00Z. Again it will be open for everybody who’s interested.