[Nut-upsdev] Proposal: "experimental" namespace for non-standard NUT variables

Jim Klimov jimklimov+nut at gmail.com
Fri May 28 02:15:05 BST 2021


Hello all,

  Looking at NUT pull request (PR) history on GitHub, I see that we have
had a non-trivial number of stalled driver contributions sharing a prominent
similarity: proposed names for some of the variables did not fit into the
list
defined at
https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt

  During discussions of these contributions, original driver authors often
did
not follow up with a fix for naming, which sometimes was not as trivial as a
team member picking a name from the existing list and just patching the pull
request, but needed understanding the purpose of a data point in silence,
and perhaps soliciting a community approval to name some really new
concept. Note that by being neither developers nor users of such driver,
the core NUT team members can quite make a poor uneducated guess
about the meaning of the new data point.

  As a consequence, we then have a pending *almost* completed driver
that can improve the practical experience for end-users, which is not
merged to the common NUT codebase because it is not *fully* completed.

  I propose to add a namespace like "experimental.*" with rather arbitrary
strings following the prefix, so that such driver contributions can get
merged
and become battle-proven by end users, and proper naming for the data
points that the driver supports (possibly including a choice of name for
some
really new stuff) can follow up later.

  It would also be clear from such prefix that the name/feature/concept
is experimental so when a standard name is eventually assigned, there
should be no major complaints from users that some string their scripts
depended on is no longer served. In fact, if they do depend on some value
like that, they can drive the effort (PR, community soliciting) to assign
that
data point a standard supported name, so reducing the burden on the few
active core team members on one hand, and helping us all benefit from
their analysis and tests, and committing a relevant final choice on another.

  What do you think?

Thanks in advance,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210528/337bbdcd/attachment.htm>


More information about the Nut-upsdev mailing list