[Nut-upsdev] Clarification to man upssched.conf

[Jim Klimov]

On July 12, 2017 10:36:15 AM GMT+02:00, Roger Price <roger at rogerprice.org> wrote:
>On Tue, 11 Jul 2017, Jim Klimov wrote:
>
>> On July 5, 2017 9:55:13 AM GMT+02:00, Roger Price
><roger at rogerprice.org> wrote:
>>> 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
>Nut-upsdev at lists.alioth.debian.org
>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