Code Quality Project for Q4 2024

Announcements
1

As part of the planning for the last quarter of 2024, we’d like to do a project focused on code quality: that is, tackling more bug reports, some legacy or backlog issues.

As we already organized an effort in Q2, we realize we need modules to be involved much earlier so each of them can

  1. Assess: look at the current state of quality in their area
  2. Define the most urgent needs
  3. Come up with a plan

What you need to know

  • We’d like to do this in December 2024 + January 2025
    • Why? Because the end of year is always hectic and that should give us enough time and space to really work on quality, while also giving more buffer to plan the next projects.
    • This means Q4 2024 for projects > October and November / Q1 2025 for projects > February and March
  • Every module is involved, except Core (@mont29), Cycles (@weizhen @lukasstockner97 ) and @deadpin as those people are already mostly working on debugging or improvements.
  • Triaging team should feel empowered to point out specific areas of interest, or specific issues needing attention @lichtwerk
  • Weekly organization: during those two months, developers on payroll should split their week between regular maintenance (incoming issues) and the quality project (which has specific targets)
  • Who can participate: it would be great to have every contributors’ support, of course!

What we want

  • Fix bugs: comb through the list, close the old ones, lower the number of open issues. Make the code cleaner.
  • Need some motivation? What about fixing or closing everything that is more than 1 year old?

Next steps

  • In the next module meetings: discuss the project and plan time to assess the needs of your area
  • Communicate your numbers, goals and priorities to Thomas and Fiona
    • No need for focus time on quality? Awesome! Let’s keep working on projects and regular maintenance.
    • Or maybe you have ideas for tests? Automations? Let’s discuss.
  • By the end of September: Fiona will get back to everyone with a proposal plan, and the overall planning for Q4

If you want help to pick priorities, please reach out to Sergey.
Let us know if you have any question!

20 Likes
2

It would be nice if that is not done automatically. This will discourage users from filing bugs. I personally stop filing bugs on Github projects after they implement auto bug closing bots because it just feels like I am wasting my time.

1 Like
3

The context is fixing not just closing reports automatically!

2 Likes
4

Please do consider addressing the longstanding issues concerning keymap corruption, duplication of keymap items, etc. as part of the fixing old bugs! :face_holding_back_tears:

5

Tho in some cases, they can just be closed.

For example: #105436 - Rigify : generating a rig from a metarig containing a spline_tentacle rig type will fail ('rig_id' is not defined error) - blender-addons - Blender Projects and #105403 - blender4.2 mac rigify (limbs.spline_tentacle) doesn't generate correctly - blender-addons - Blender Projects

That just happened to have been something I came across myself. In theory this doesn’t apply across the board, but I doubt it’s a one off.

6

yeah I know, and what I meant is that she meant closing the reports not in an automatic way! (fixing them, close them if related reports are opened already …)