2024-01-09 Blender Admins Meeting

Meetings
1

Attendees

  • Bastien Montagne
  • Brecht Van Lommel
  • Campbell Barton
  • Dalai Felinto
  • Fiona Cohen
  • Francesco Siddi
  • Philipp Oeser
  • Sergey Sharybin
  • Thomas Dinges

Notes

  • Approved policy for license headers: License Headers - Blender Developer Documentation
  • Always do subversion bumps
    • There is no reason nowadays not to bump the code subversion immediatelly upon code change - as opposed to put code into the /* Versioning code until next subversion bump goes here. */ blocks.
    • Will reduce extra work and conflicts on release (branching) (Bcon3/Bcon5).
  • High Priority reports number is still very high (45+), with many of them being more than 1-2 months old.

2024-Q1 Projects

  • Each project should have a landing page
    • i.e., a task on gitea with a list of upcoming steps/tasks where people can see the status of the project and get involved.
    • Yet to be defined where this should be aggregated.
  • Time availability
    • Developers still want (and are expected) to help with module maintainance.
    • It is important for developers to be upfront about their availability for the projects, so things can be planned accordingly.
    • Communication about expected (or proposed) individual availability to be held during the respective projects kick-offs.
  • Go-to bf-admin
    • To balance the individual responsibilities, and given who is already involved on the projects the go-to admin for some projects were shifted:
      • Bastien: Grease Pencil
      • Brecht: Brush Assets, EEVEE Next
      • Campbell: Extensions Platform
      • Sergey: GPU Compositor
      • Dalai: Character Animation
    • It is up to the admins to communicate that to their respective projects.
    • It is also good to clarify with the projects leads what the admin consulting role means in the context of a project.

Follow ups:

  • Bastien Sergey will send an email on behalf of the admins to raise the awareness of the high priority bug situation.
  • Thomas will add an updated comment in the code saying that subversion should be bumped, and do-versioning handled as part of the code submission.
  • All admins: make sure the projects have a clear landing page, and are informed about your involvement.
8 Likes
2
3

Agreed about this, but what about removing these sections then? They’ve always been one of the more confusing parts of the versioning code for new developers anyway.

4

Thomas will come up with a PR for this, so we can leave specifics for then. Personally I think having a comment block there that explains how to proceed is nice. At least during a transition period.

I haven’t given much thoughts to what we keep from the existing code vs what should stay. So I may have misrepresented the upcoming solution while writing the notes.

1 Like
5

The PR can be found here #116945 - Versioning: Update comment how to handle subversioning - blender - Blender Projects

6

I’m probably missing something, so this might be more a question than a comment.

But I’ve always used the /* Versioning code until next subversion bump goes here. */ section as a temporary place to put versioning code in a PR while it is being reviewed. Then once approved I do the version bump, move that version code out into its own section, update the PR, and then merge.

If not doing it this way then the PR contains the current blender version so won’t it then conflict all the time while awaiting approval?

1 Like
7

You can still do that for PRs before final commit, even though the block is gone in main. The reason behind the change is, that a proper version bump is always done on code submission now, rather than putting it into the temporary block and keep it there for weeks.