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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >>> >>
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
