Nut upsdev - May 2021 - Proposal: "experimental" namespace for non-standard NUT variables

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-upsuser/attachments/20210528/337bbdcd/attachment.htm>

On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote:
> ? 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
> ? I propose to add a namespace like "experimental.*"
The future RFC refers to the file nut-names.txt as the "Recording
Document" for
variable names, thus giving it the authority of the RFC.   It would be useful to
clarify this in the introductory paragraph beginning "This is a
dump...".  It is
more than a dump. The process for adding a variable name to NUT could be 
formalised under a new heading such as "Process for adding new variable
names".
The text following that heading could then introduce experimental.... variables.

Roger