[Nut-upsdev] release?

[Jim Klimov]

I more or less agree that the release is due (or overdue, considering an
earlier hope for half-a-year cadence).

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:
* make USB report "fixup" optional by device configurations
(disable_fix_report_desc: not all devices with same IDs are equivalently
buggy) - https://github.com/networkupstools/nut/issues/1566 /
https://github.com/networkupstools/nut/pull/1575;
* 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
https://github.com/networkupstools/nut/issues/1512 (at least began as a
regression discussion) which is not closed yet, in particular;
* a "conveniently sorted" array introduced a bug, for that one driver the
original entry order was there for a reason -
https://github.com/networkupstools/nut/issues/1427;
* a driver that did not start unless debugged -
https://github.com/networkupstools/nut/issues/1455;
* battery.voltage and battery.charge estimation in Qx drivers was not
always useful/meaningful - in testing
https://github.com/networkupstools/nut/pull/1652/ /
https://github.com/networkupstools/nut/issues/1279;
* not sure OTOH if usbhid-ups crash upon reconnect was a regression after
2.7.4 - fixed in https://github.com/networkupstools/nut/pull/1632

I've recently cleaned up https://github.com/networkupstools/nut/milestone/8
(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
:)

Jim


On Mon, Jan 9, 2023 at 5:17 PM Greg Troxel <gdt at lexort.com> wrote:

> It seems we have crossed the threshold where regular people are better
> off with git master vs the most recent formal release.  Particularly
> because packaging systems package actual releases, that leads to a
> release being overdue.
>
> There are infinite things to improve, and 536 open issues.   My view is
> that a release needs to only have some degree of improvement (which git
> master clearly does) and not have significant regressions.
>
> I therefore wonder about:
>   - let's try to shake out regressions and bugs in code new to the release
>   - defer fixes that aren't regressions
>   - get 2.8.1 out
>
> and then continue hacking.
>
> From the packager viewpoint, it takes 10 minutes to update to a release,
> plus time to adapt to changes.  So as long as releases are not more than
> every few months on average, there's no issue.
>
> (There's a related issue about asking users filing bugs to retest with
> the latest release, which argues for having that release be fairly
> recent.)
>
> (There is windows binaries, but I don't see that as a regression and I
> don't see anyone actively working on it.)
>
> What's in the regression category, once python searching is updated?
>
> Greg
>
> _______________________________________________
> 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/20230109/063d1f16/attachment-0001.htm>