[Nut-upsdev] release?

Jim Klimov jimklimov+nut at gmail.com
Fri Oct 27 19:29:54 BST 2023


Hello, fellow NUTs!

  This October proved to be a rather productive month, with several
developments wrapped up, as well as some issues with master codebase
behavior created, reported, fixed and tested :)
  While we were not part of some official Hacktoberfest this year, it
pretty much felt like one - great thanks to everyone involved!

  The month is also ending soon, so if we're to follow up with the hope to
release NUT v2.8.1 "during October" - there's only so few days to make it
happen.

  People are hereby welcome to give the current code a spin to try and
discover any blocker issues, "or forever hold their silence" (well, till
next release). I'm a bit concerned especially regarding real-life important
behaviors like shutdown handling - there were several layers changes to
`upsmon` regarding support of administrative-OFF, BYPASS and CALibration
states vs. OL/OB and/or loss of connection to data server. Hopefully we
tuned the state machine better with each iteration, but any glaring issues
would better be found and fixed before the release. Some changes also
arrived to the `nutshutdown` script that is typically part of
systemd-shutdown endgame, but could be used in other platforms as well.
Earlier changes since 2.8.0 also touched `upssched` and ability of driver
daemons to initiate shutdown (as an alternative to killing the daemon and
starting another copy for `drivername -K` action which would take time
again to detect and initialize the device), for example, although the
latter is primarily just an option for future integrations and is not
immediately beneficial out of the box today.

  Another important recent improvement is the addition of an `apc_modbus`
driver to support the APC ModBus protocol (currently for read-only
monitoring - I am not sure if development for commands and writable
variables would land before the end of month).

  Generally you can preview the live list of notable changes since 2.8.0
release at
https://networkupstools.org/docs/release-notes.chunked/NUT_Release_Notes.html#_planned_release_notes_for_nut_2_8_1_what_8217_s_new_since_2_8_0
and for things that are expected to impact packaging and upgrades (whether
by possibly breaking disruption, or by adding new ways to automate things
more efficiently that the audience could benefit from) - at
https://networkupstools.org/docs/release-notes.chunked/NUT_Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1
- with such release notes publication also being a recent addition.

Jim Klimov


On Mon, Oct 2, 2023 at 5:50 PM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> Seconding ...  or firsting, considering the recent call to testing hidden
> somewhere in a recent mail post ;) Currently I'm aiming at cutting a NUT
> 2.8.1 release during October.
>
> As a bit of self-imposed retrospective:
>
> I did hope for a faster (quarterly or so) cadence when I made the 2.8.0
> release, but then a few issues came up as regressions of 2.8.0 and it
> became a sort of crusade to fix them all before 2.8.1. Perhaps it was a
> flawed decision (I can now see the benefits of issuing releases so
> packaging can include the fixes as soon as serious flaws are discovered and
> addressed).
>
> Another big wad of work (which is not necessarily a release blocker, but
> happened to act as such) is an update of HCL (in NUT main sources) and DDL
> (another repo). In particular, it felt important (maybe indeed wrong in
> practice, especially in hind-sight) to have each release include the
> reports of devices supported by it (or at least by the earlier codebase).
> Many confirmations come from the current master branch state of that day,
> so it is part of NUT support for the snapshot release.
>
> For now, myself and various GitHub issue-posters happen to be practically
> going over different build scenarios to find recipe flaws and avoidable
> warnings (especially with new compiler releases) that could compromise the
> actual or perceived quality of the next NUT release. One puzzling case at
> the moment is a failed `make distcheck` that I can't reproduce anywhere,
> which involves apparent lack of man page source files in the build area -
> which I can't make happen even on a minimally installed container. FWIW =>
> https://github.com/networkupstools/nut/issues/2081
>
> Some other issues remain marked in the 2.8.1 milestone, some recently
> addressed, others pushed to later releases, most of the remainder being
> about HCL/DDL updates.
>
> A couple of driver contributions are actively brewing (including
> long-awaited APC-ModBus support), so I'm looking out for the opportunity to
> merge them too, so the upcoming release lets the greater public see them
> and report back...
>
> Jim
>
>
> On Mon, Oct 2, 2023 at 5:06 PM Greg Troxel <gdt at lexort.com> wrote:
>
>> I stuck in a comment in an issue, but I think we're overdue, picking 6
>> months as arbitrary.
>>
>> I just created a snapshot privately.  It passes make check on netbsd 9
>> amd64.  I am updating pkgsrc-wip, which involves adjusting a lot of
>> packages that I believe have been merged (yay!).
>>
>> I wonder if anybody thinks that git master has regressions from 2.8.0
>> right now.   I ask this partly about release, and partly because I'm
>> going to try it.
>>
>>
>>
>> _______________________________________________
>> Nut-upsdev mailing list
>> Nut-upsdev at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20231027/ba01adff/attachment.htm>


More information about the Nut-upsdev mailing list