Replies: 1 comment
-
IMO the "other" classifications are a stop-gap, and we should discourage its use in the "official" definitions. I'm in favor of restricting the use of "other" for all component types in the absence of a solid argument otherwise. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What would everyone's thoughts be on restricting the usage of "other" for a interface (or other connection type) in the devicetype library.
The main driver is:
#9098 in netbox, which is potentially going to open up "other" for more types, and thinking about it
In the device type library I think it would make more sense to have well-defined types being used instead of other so we don't just end up with a bunch of "other" interfaces/ports/etc
One option would be to adjust the CI to see if we can flag a warning or maybe have an optional check to see if there are types with "other" in them and throw a warning but not block merge.
Just some thoughts, feel free to add any comments
Beta Was this translation helpful? Give feedback.
All reactions