Jim Klimov
2021-May-28 01:15 UTC
[Nut-upsuser] 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>
Roger Price
2021-May-28 06:43 UTC
[Nut-upsuser] [Nut-upsdev] Proposal: "experimental" namespace for non-standard NUT variables
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
Reasonably Related Threads
- Proposal: "experimental" namespace for non-standard NUT variables
- Proposal: "experimental" namespace for non-standard NUT variables
- Proposal: "experimental" namespace for non-standard NUT variables
- Proposal: "experimental" namespace for non-standard NUT variables
- Proposal: "experimental" namespace for non-standard NUT variables