<div dir="ltr"><div>Hello all,<br></div><div><br></div><div> 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.</div><div><br></div><div> 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.</div><div><br></div><div>Thanks again,</div><div>Jim Klimov</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 27, 2023 at 8:29 PM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello, fellow NUTs!</div><div><br></div><div> 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 :)</div><div> While we were not part of some official Hacktoberfest this year, it pretty much felt like one - great thanks to everyone involved!</div><div><br></div><div> 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.</div><div><br></div><div> 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.<br></div><div><br></div><div> 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).</div><div><br></div><div> Generally you can preview the live list of notable changes since 2.8.0 release at <a href="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" target="_blank">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</a> 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 <a href="https://networkupstools.org/docs/release-notes.chunked/NUT_Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1" target="_blank">https://networkupstools.org/docs/release-notes.chunked/NUT_Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1</a> - with such release notes publication also being a recent addition.<br></div><div><br></div><div>Jim Klimov<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 2, 2023 at 5:50 PM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>As a bit of self-imposed retrospective:<br></div><div><br></div><div>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).<br></div><div><br></div><div>
<div>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.<br></div><div><br></div>
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 => <a href="https://github.com/networkupstools/nut/issues/2081" target="_blank">https://github.com/networkupstools/nut/issues/2081</a></div><div><br></div><div>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.</div><div><br></div><div>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...</div><div><br></div><div>Jim<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 2, 2023 at 5:06 PM Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I stuck in a comment in an issue, but I think we're overdue, picking 6<br>
months as arbitrary.<br>
<br>
I just created a snapshot privately. It passes make check on netbsd 9<br>
amd64. I am updating pkgsrc-wip, which involves adjusting a lot of<br>
packages that I believe have been merged (yay!).<br>
<br>
I wonder if anybody thinks that git master has regressions from 2.8.0<br>
right now. I ask this partly about release, and partly because I'm<br>
going to try it.<br>
<br>
<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>