NetBox maintainers meeting minutes, 25 Jan 2024

[jeffgdotorg]

NetBox maintainers meeting minutes, 25 Jan 2024

Maintainer meeting cadence (Jeremy)

• Maintainer meetings will be weekly, perfect attendance not mandatory, going forward

Plan for slim-select library (Jeremy)

• Upgrading to slim-select v2 will be almost a full rework because the v2 API is in no way backward-compatible
• Benefits of tom-select include:
• ↳ Nice features, especially templating (ref discussion, below, of Ability to display additional relevant context data within the select UI #13283)
• ↳ Seems more stable, well maintained
• ↳ Better docs
• ↳ Slightly more GH stargazers than slim-select
• Discussion:
• ↳ Arthur: Concur on popularity and stability
• ↳ Jeremy: The templating support in tom-select is really neat. Not Jinja2-level templating, but still powerful.
• ↳ Jeremy: We have to choose either slim-select v2 or tom-select. I'll move forward with the one we choose.
• ↳ Jeremy: There are challenges, including that NetBox API's brief flag is binary. We'll figure that out.
• Decision: Move to tom-select. Jeremy will start work on this very soon. Once the move is made, we can start the work to leverage its templating support for Ability to display additional relevant context data within the select UI #13283.

GraphQL: Strawberry vs. graphene-django (Arthur)

• Issue Replace graphene-django with Strawberry #9856 has the full history.
• We use graphene-django today. It's effectively abandonware.
• Strawberry is much more well maintained.
• Strawberry does not currently support Django filters. It did before but its maintainers ripped out support.
• Strawberry makes a lot of releases.
• The main thing that has tied us to graphene-django has been its support for django-filter.
• Strawberry has its own filtering implementation, which may operate differently.
• Should we kick this down the road again, waiting for graphene-django to become better maintained? Or go with Strawberry, knowing that the frequent releases will be a liability?
• Discussion:
• ↳ Jeremy: The removal of django-filter support from Strawberry feels like a real risk / bad omen, feels like an arbitrary decision
• ↳ Jeremy: There's not a 1.0 release of Strawberry. Releases frequently come just a day or two apart. Active development is a good thing, but bordering on one release per commit is just bonkers.
• ↳ Jeremy: We don't have to reach a decision on this call, but we do need one soon. End of January is next week, and NetBox v4.0b1 is due 01 April. Both possibilities make me nervous.
• ↳ Dan: I don't think the lack of django-filter support is too bad, given the available workaround, maybe we can automate the workaround in a way that's not too burdensoms. As long as we're able to maintain most of the filtering mechanics that we have today, Strawberry might be worh it.
• ↳ Jeremy: Do we know why Strawberry dropped support for django-filter? Arthur: It appears to be just happenstance / oversight. Jeremy: That does not instill confidence.
• ↳ Jeremy: If we do stick with graphene-django, we will need to update to the latest release.
• ↳ Dan: Have we also been looking at the strawberry-graphql-django repo? Their issue Filtering & Ordering overhaul #399 (open) may be informative.
• ↳ Dan: could NetBox Labs help fund Strawberry, or contribute some hands-on-keyboard time? Jeremy: We could explore that. Jeff: Working or giving upstream FTW.
• Decision: defer. Jeremy and Arthur will explore a bit further and we will make a decision. Time-boxed to no later than 31 Jan (date of next maintainers call).

Proposal: Maintainers to serve for a fixed term without term limits (Jeff)

• Goal: Mitigate burnout by providing an automatic out that does not close the door
• Jeremy: Implementing this idea gives us the ability to set expectations for new maintainers about the minimum time commitment to get onboarded. Also gives everybody an automatic out. Feel either 4 or 6 months is a sweet spot, and also aligns somewhat with our release cadence.
• Dan: We discussed something similar in April 2023 (one meeting before Abhi joined).
• Jeff: We can also consider adding emeritus status
• Abhi: What would the criteria be for a new maintainer to apply? Jeremy: Not decided, but might involve e.g. having a certain number of PRs merged. We should decide and formalize that.
• Jeff: I will endeavor to have a more formal, fleshed-out proposal (similar to the one floated in April 2023) in time for next week's meeting.

Interactive advice on approaching Cascades event rule when the associated script is deleted #14869 (Abhi)

• Jeremy: This is a little bit wonky because reports and scripts currently are not fully-fledged objects with reflections in the database.
• Arthur and Jeremy will dig into this a little bit. Work on Maintain database representations of reports & scripts #14438 (planned for v4.0 but currently blocked by Remove support for reports in NetBox v4.0 #12510) should help.