<div dir="ltr"><div>Thanks Roger for the proposed changes, now they are largely incorporated into this PR: <a href="https://github.com/networkupstools/nut/pull/1046">https://github.com/networkupstools/nut/pull/1046</a></div><div><br></div><div>For the community at large: can I assume everyone with an opinion about this introduction of "experimental.*" prefix for contributor-defined concepts in new NUT drivers to fast-track merging of their contributions (especially where it stalled for months and original authors walked offline), agrees with such change?</div><div><br></div><div>In the coming weeks I hope to go over such stalled PRs (and some recent merges, e.g. of <a href="https://github.com/networkupstools/nut/pull/975">https://github.com/networkupstools/nut/pull/975</a>) to make the codebases adhere to the changed standard (by adding the prefix) and so get more drivers into main NUT tree and less PRs stalled.</div><div><br></div><div>It would be very welcome if someone beats me to that and proposes better names right away before PRs are merged ;)</div><div><br></div><div>Some points to look at (there may be some I missed in the cursory search) include:</div><div>* <a href="https://github.com/networkupstools/nut/pull/431/files#diff-acced4571bb1961933a847e91d650ece737286bab496e4875d86b058a7c4606fR461">https://github.com/networkupstools/nut/pull/431/files#diff-acced4571bb1961933a847e91d650ece737286bab496e4875d86b058a7c4606fR461</a> - nearly all of this mapping table</div><div>* <a href="https://github.com/networkupstools/nut/pull/440/files#diff-1b4631911522ab81e231e820b924995818fedb54e89bc7efaf5faee1d2b70c37R228">https://github.com/networkupstools/nut/pull/440/files#diff-1b4631911522ab81e231e820b924995818fedb54e89bc7efaf5faee1d2b70c37R228</a></div><div><br></div><div>Jim Klimov<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 28, 2021 at 1:09 PM Roger Price <<a href="mailto:roger@rogerprice.org">roger@rogerprice.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 28 May 2021, Roger Price wrote:<br>
> On Fri, 28 May 2021, Jim Klimov via Nut-upsdev wrote:<br>
><br>
>>   Looking at NUT pull request (PR) history on GitHub, I see that we have had <br>
>> a non-trivial number of stalled driver contributions sharing a prominent <br>
>> similarity: proposed names for some of the variables did not fit into the <br>
>> list defined at <br>
>> <a href="https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt</a><br>
><br>
>>   I propose to add a namespace like "experimental.*"<br>
><br>
> The future RFC refers to the file nut-names.txt as the "Recording Document" <br>
> for variable names, thus giving it the authority of the RFC.   It would be <br>
> useful to clarify this in the introductory paragraph beginning "This is a <br>
> dump...".  It is more than a dump. The process for adding a variable name to <br>
> NUT could be formalised under a new heading such as "Process for adding new <br>
> variable names".<br>
> The text following that heading could then introduce experimental.... <br>
> variables.<br>
<br>
I suggest replacing the first paragraph of the file nut-names.txt with the <br>
something like the following:<br>
<br>
              RFC xxxx Recording Document<br>
              ---------------------------<br>
        NUT variable names and instant commands<br>
        ---------------------------------------<br>
<br>
This document is defined by RFC xxxx and referenced as the document of record <br>
for the variable names and the instant commands used in the protocol described <br>
by the RFC.<br>
<br>
On behalf of the RFC this document records the names of variables describing the <br>
abstracted state of a UPS, and the instant commands sent to the UPS using <br>
command INSTCMD, as used in commands and messages between the Attachment Deaemon <br>
(upsd) and the clients.  Developers should use the names recorded here.<br>
<br>
If you need to express a state which cannot be described by any existing name, <br>
make a request to the NUT developer's mailing list for assignment of a new name. <br>
Clients using unrecorded names risk breaking at a future update.  If you wish to <br>
experiment before obtaining your requested variable name, you should use a name <br>
of the form experimental.x.y<br>
<br>
Put another way: if you make up a name that's not in this list and it<br>
gets into the tree, and then we come up with a better name later, clients<br>
that use the undocumented variable will break when it is changed.<br>
<br>
NOTE: In the descriptions, "opaque" means programs should not attempt to parse <br>
the value for that variable as it may vary greatly from one UPS to the next. <br>
These strings are best handled directly by the user<br>
<br>
Roger_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>