<div dir="ltr"><div>I more or less agree that the release is due (or overdue, considering an earlier hope for half-a-year cadence).</div><div><br></div><div>Regression-wise, there were a few complaints specific to 2.8.0 changes vs. 2.7.4 which I think have got addressed, though not quickly sure if all of them were - which became a large part of the delay:</div><div>* make USB report "fixup" optional by device configurations (disable_fix_report_desc: not all devices with same IDs are equivalently buggy) - <a href="https://github.com/networkupstools/nut/issues/1566">https://github.com/networkupstools/nut/issues/1566</a> / <a href="https://github.com/networkupstools/nut/pull/1575">https://github.com/networkupstools/nut/pull/1575</a>;<br></div><div>* some discussions of mis-processing of generally applied USB LogMin/LogMax fixups for invalid encoding happened, not sure OTOH if solutions (e.g. an option to not do it) were proposed in the end... I think it was the <a href="https://github.com/networkupstools/nut/issues/1512">https://github.com/networkupstools/nut/issues/1512</a> (at least began as a regression discussion) which is not closed yet, in particular;</div><div>* a "conveniently sorted" array introduced a bug, for that one driver the original entry order was there for a reason - <a href="https://github.com/networkupstools/nut/issues/1427">https://github.com/networkupstools/nut/issues/1427</a>;</div><div>* a driver that did not start unless debugged - <a href="https://github.com/networkupstools/nut/issues/1455">https://github.com/networkupstools/nut/issues/1455</a>;</div><div>* battery.voltage and battery.charge estimation in Qx drivers was not always useful/meaningful - in testing <a href="https://github.com/networkupstools/nut/pull/1652/">https://github.com/networkupstools/nut/pull/1652/</a> / <a href="https://github.com/networkupstools/nut/issues/1279">https://github.com/networkupstools/nut/issues/1279</a>;</div><div>* not sure OTOH if usbhid-ups crash upon reconnect was a regression after 2.7.4 - fixed in <a href="https://github.com/networkupstools/nut/pull/1632">https://github.com/networkupstools/nut/pull/1632</a> <br></div><div><br></div><div>I've recently cleaned up <a href="https://github.com/networkupstools/nut/milestone/8">https://github.com/networkupstools/nut/milestone/8</a> (goals of 2.8.1), delaying some 40 issues and PRs to subsequent releases and keeping the few which I want to take a look at actually fixing before cutting it (or also delaying). Recent X-mas/NewYear burst of activity for packaging recipes, upsmon complaints, systemd and several other subjects was part of that purge: delaying is not the only way to address the backlog :)</div><div><br></div><div>Jim<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 9, 2023 at 5:17 PM Greg Troxel <<a href="mailto:gdt@lexort.com">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">It seems we have crossed the threshold where regular people are better<br>
off with git master vs the most recent formal release.  Particularly<br>
because packaging systems package actual releases, that leads to a<br>
release being overdue.<br>
<br>
There are infinite things to improve, and 536 open issues.   My view is<br>
that a release needs to only have some degree of improvement (which git<br>
master clearly does) and not have significant regressions.<br>
<br>
I therefore wonder about:<br>
  - let's try to shake out regressions and bugs in code new to the release<br>
  - defer fixes that aren't regressions<br>
  - get 2.8.1 out<br>
<br>
and then continue hacking.<br>
<br>
>From the packager viewpoint, it takes 10 minutes to update to a release,<br>
plus time to adapt to changes.  So as long as releases are not more than<br>
every few months on average, there's no issue.<br>
<br>
(There's a related issue about asking users filing bugs to retest with<br>
the latest release, which argues for having that release be fairly<br>
recent.)<br>
<br>
(There is windows binaries, but I don't see that as a regression and I<br>
don't see anyone actively working on it.)<br>
<br>
What's in the regression category, once python searching is updated?<br>
<br>
Greg<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>