[Nut-upsdev] Clarification to man upssched.conf

[Roger Price]

I would like to add a sentence to the man page for upssched.conf.

After the sentence

"Note that any AT that matches both the notifytype and the upsname for the
current event will be used."

I propose adding the sentence

"If more than one AT matches the notifytype and upsname, the AT
declarations are executed in the order in which they appear in
upssched.conf.

This is the current behaviour so there is nothing to do technically, but I
would like this behaviour to become recognized and permanent, and not
unofficial and possibly ephemeral as at present.

Why? The current behaviour makes it possible to restart a timer on a
given event, for example by writing

AT ONBATT ***@localhost CANCEL-TIMER heartbeat-failure
AT ONBATT ***@localhost START-TIMER heartbeat-failure 660

For this to work, it is essential that the AT's are executed in the order
they are written.

Roger

[Jim Klimov]

Post by Roger Price
I would like to add a sentence to the man page for upssched.conf.
After the sentence
"Note that any AT that matches both the notifytype and the upsname for the
current event will be used."
I propose adding the sentence
"If more than one AT matches the notifytype and upsname, the AT
declarations are executed in the order in which they appear in
upssched.conf.
This is the current behaviour so there is nothing to do technically, but I
would like this behaviour to become recognized and permanent, and not
unofficial and possibly ephemeral as at present.
Why? The current behaviour makes it possible to restart a timer on a
given event, for example by writing
For this to work, it is essential that the AT's are executed in the order
they are written.
Roger
_______________________________________________
Nut-upsdev mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Your proposal and reasoning make sense to me :)

I wonder if it would be more valuable and visible if such "direct change" suggestions were added as pull requests on github, with much of the description posted there and an email to pass the URL (and maybe a pitch of the idea) and so stir up discussion in community?.. It is not too much hassle after initial repo-cloning setup, at least where people expect to contribute more than once.

Jim
--
Typos courtesy of K-9 Mail on my Redmi Android

[Roger Price]

Post by Jim Klimov

Post by Roger Price
I propose adding the sentence
"If more than one AT matches the notifytype and upsname, the AT
declarations are executed in the order in which they appear in
upssched.conf.

Your proposal and reasoning make sense to me :)
I wonder if it would be more valuable and visible if such "direct
change" suggestions were added as pull requests on github, with much of
the description posted there and an email to pass the URL (and maybe a
pitch of the idea) and so stir up discussion in community?.. It is not
too much hassle after initial repo-cloning setup, at least where people
expect to contribute more than once.

My understanding was that this is the mailing list to discuss such things.

I could learn about git, but I don't fancy setting up a git server. I've
been retired now for nearly 20 years and I would prefer spending more time
on other things. I'm not sure that git activity would generate more
discussion, or acceptation.

If the young guys pick up the suggestion, that's fine, but if in some
future release of NUT, AT's are executed in random order, I have a
solution which will keep the heartbeat working, so it's not a problem for
me.

Best Regards, Roger

[Jim Klimov]

Post by Jim Klimov

On July 5, 2017 9:55:13 AM GMT+02:00, Roger Price

Post by Roger Price
I propose adding the sentence
"If more than one AT matches the notifytype and upsname, the AT
declarations are executed in the order in which they appear in
upssched.conf.

Your proposal and reasoning make sense to me :)
I wonder if it would be more valuable and visible if such "direct
change" suggestions were added as pull requests on github, with much

of

the description posted there and an email to pass the URL (and maybe

a

pitch of the idea) and so stir up discussion in community?.. It is

not

too much hassle after initial repo-cloning setup, at least where

people

expect to contribute more than once.

My understanding was that this is the mailing list to discuss such things.
I could learn about git, but I don't fancy setting up a git server.
I've
been retired now for nearly 20 years and I would prefer spending more time
on other things. I'm not sure that git activity would generate more
discussion, or acceptation.
If the young guys pick up the suggestion, that's fine, but if in some
future release of NUT, AT's are executed in random order, I have a
solution which will keep the heartbeat working, so it's not a problem for
me.
Best Regards, Roger
_______________________________________________
Nut-upsdev mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Well... you have a good point there.

There's documented project guideline for interaction with and between community members. Email has been around for eternity, and mailing list logs are easily kept by multiple subscribed services. So it is certainly beneficial to have discussions here, especially general questions like "would it make sense to...?"

On another hand, developers that do already have a git-based setup (which is a majority nowadays) and a habit for its workflows can find it more convenient to discuss and test proposed codebase changes (where docs are also part of codebase) right in the system for tracking and CI-testing the code. In that case it may be useful to post a "pull request" (aka PR) on GitHub with changes that a contributor suggests and which other people can quickly check out, build and test on their systems - and notify general public about that PR via email to proceed with discussion wherever it makes more sense. There have been many things in the past year or two where discussions happened purely within github and changes were competently reviewed and amended and ultimately merged.

Of course, it makes little sense to learn and set up git just to propose a couple of sentences in a README. But if one expects to build NUT, or research its codebase locally, or even try out and propose changes - and especially if more than once - then it is the way to go. Also, one does not have to set up a git server: github has one for people like us to exchange open-source codebases. You just need a standard git client (able to clone, pull, add, commit and push changes) of which there are plenty, and a text editor.

Jim
--
Typos courtesy of K-9 Mail on my Redmi Android