Hello all,
Thanks to everyone who chimed in with tests, ideas and even freshly
confirmed regressions introduced by NUT v2.8.0 release compared to v2.7.4
(yes, there were after all a few eggs broken to make that omelette, with
all the code clean-up that went into it), so now I feel more confident
about the upcoming release being usable out-of-the-box (e.g. packaged) for
more people than v2.8.0 "vanilla" happened to be in hindsight.
Given the seasonal timing, we're still aiming for a Halloween Edition (oh
well, maybe just a release at a neat date...) so y'all have another day to
check the recent master branch buildability and behavior... perhaps with a
focus specifically on the changes that landed with the most recent fixes in
the past few days.
Thanks again,
Jim Klimov
On Fri, Oct 27, 2023 at 8:29 PM Jim Klimov wrote:
> 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 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
