Nut upsdev - Nov 2020 - [EXTERNAL] Updates to NUT project leadership

Hello all,

I am excited to see the first replies, even if some seem to be private
messages. Thank you all! :)


In the following case, I think the raised question pertains to many
contributors on this list, so would answer publicly - and thanks for asking.

> There are various GitHub issues and Dev mailing list inquires, but they
haven't really gone anywhere.
> Can you provide some guidance on what the right way to help push these
things along are and what I can do from my end to help?
> e.g. protocol information, testing, etc

First of all, thanks for what you are doing!

Although I have been in the core team for quite a while, I am still
learning about some processes and traditions we have in the NUT project,
and resources (including people) that are available. As in many projects,
the active population in terms of, say, regularly available man-hours per
month, is a bottleneck - sad but true.

Certainly, publishing the vendors' official protocol information to get
drivers made or updated, and testing the results with varied hardware to
make sure nothing begins to crash and new features do actually work, are
both very important parts of the equation, so great thanks for offering and
providing such help. Don't forget to PR your company and yourself into the
`docs/acknowledgements.txt` file, by the way.

But in the end, what matters for code improvements are codebase changes,
and things move a lot faster when everybody puts an effort into that - e.g.
providing pull requests to update the documentation library with protocol
data, pull requests updating or introducing drivers, reviews of changes
somebody proposed, and so on. As it happens, in NUT as well as in many
other projects I see, if the core team's day job is not to directly develop
the product, then the central folks are overwhelmed by the commitments they
already have and are rather short on time (can not pick up development
ourselves).

We want and can help the project and its greater community move forward, by
orchestrating it to happen and making sure new proposals fit well together
with the existing codebase, but other people should step up and provide
those new features in code. As much as it might be fun to code all that, I
am too aware of the years-long backlogs I have on some efforts, and do not
want to be the bottleneck on progress other people can make (by themselves,
or enticing someone to) and I can just stand nearby to help them make it
the best we can.

For example, on my side - I spent the past month by cleaning up the NUT
code base, so it is more maintainable and passes green on many more CI
setups than it did, against many revisions of C standard, on several
compilers and operating systems, and does not spew warnings even in many
pedantic cases. I hope this would help us all be more confident that new
contributions (including stuff that is in the queue for way too long, such
as importing one of the branches offering libusb-1.x support) do not
introduce apparent regressions, while developers can run the same script as
CI does to check for same test conditions locally and avoid posting bugs
even in their initial commits. Modern compilers and linters do a decent job
at predicting issues with code (and asking different tools on different
systems gives a lot more different answers for the same question), so not
all of the past month's changes were style and cosmetics ;) Even for cases
that are not fully green yet, developers would not drown in the issued
warnings irrelevant to *their* changes and so can focus on bringing their
contribution into perfect shape, when needed.

Hope this helps,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20201113/8080a6b3/attachment.html>