2.8.1 Release date

[SimonFair]

is there a date for the release of 2.8.1?

[biergaizi]

Duplicate of #1769.

TL;DR: Unfortunately, this project currently has no stable release schedule in any shape, beyond a milestone with tagged issues. I proposed an annual or biannual release cycle in #1769, but so far it has not been adopted by the project maintainer, and the official advise is "build from git."

[jimklimov]

Well, FWIW I proposed that people pick up not only development where interesting, but also some chores like the hundred or so HCL/DDL tickets to copy-paste into the respective data stores (and see similarities between things that do not work, to define and assign tags or new tickets to group and highlight some consistently weak area as future work), or docs brush-up where people have their pet peeves "I've read for a week and still don't understand it" - can't do this all everywhere quickly alone :)

And that's beside some head-scratching issues like #1279/#1652 where I need a few quiet hours, maybe days, in a row to sit down and understand why it (mis-)behaves like it does, as a possible regression from an earlier release. Those "X time units in a row" seem like some impossible goal, and then getting to do some dayjob or other quests for a few months - and gotta dive back into the context to make heads or tails of it again and again... ;(

Other than that, I was eager to stick to some quicker schedule (perhaps even quarterly), but untied loose ends bogged me down. Maybe gotta learn to let go and keep high-hanging fruits in errata... maybe that would grow the community to have people scratch their itches - that's what moves FOSS mostly :)

[biergaizi]

FWIW I proposed that people pick up not only development where interesting, but also some chores like the hundred or so HCL/DDL tickets to copy-paste into the respective data stores

Hmmm, if the vast majority of the tasks are just "adding model numbers into the HCL/DDL tables", I think it's something I can do to accelerate the pace of development.

And that's beside some head-scratching issues like #1279 / #1652 where I need a few quiet hours, maybe days, in a row to sit down and understand why it (mis-)behaves like it does, as a possible regression from an earlier release.

The problem with a device driver project like NUT is that it's impossible to do anything as a developer without access to the hardware, otherwise I'd be more than happy to help chasing those problems...

[jimklimov]

Well, actually much of this was and still is developed without access to hardware. Some things are primarily "theoretical" first and HW-dependent second, so tuning the code based on user logs does work (see e.g. recent tickets with nutdrv_qx fixes). Of course, corner cases do need the HW/FW with all its bugs and mis-implementations to poke with code iterations, but not all of the work requires it.

Hmmm, if the vast majority of the tasks are just "adding model numbers into the HCL/DDL tables", I think it's something I can do to accelerate the pace of development.

Much of it is tedious but not difficult - looking at reports, most are already tagged into project https://github.com/orgs/networkupstools/projects/3/views/1 - so "TODO/No Status" ones; checking what the dumps and comments were; sorting those into comment-tags for the DEV file format, and naming the result files into nut-ddl properly for the parser to render them on the site. In the last sitting took me at least a day to progress through a dozen tickets, but many had many dumps, and comments, and highlights what was #BAD: ... in a particular release and data dump (and perhaps became better/fixed later)...
And in parallel, checking if nut::data/driver.list.in has those vendors and models and drivers listed as something workable (for HCL) if the data dumps were about successful experiences.

[jimklimov]

And FWIW there are a number of issues logged about refactoring and generalization of various ideas, like to have subdriver parameter for usbhid-ups #1369, or to have runtimecal everywhere e.g. #1842, or to couple IETF MIB (or even a chain of MIBs - e.g. Eaton devices also inherited MGE, PW, PXGX... MIBs) to fallback for unavailable data in SNMP drivers - not sure if this one was logged, beside a general "multipathing driver" idea; or to teach upsmon to shut down earlier than primary's FSD - based on charge % or remaining run-time (separately per client computer); or even walking the last steps for Windows packaging (installer and USB pre-config) and the few known-missing portability bits. Things like these are "pure" programming and not quite related to particular power device availability.

[awused]

You've listed a lot of open issues, but not why those are blocking 2.8.1. Unless it's a known regression from 2.8.0 to git head, it doesn't seem like it needs to be blocking 2.8.1's release, at least not from my perspective. 2.8.0 introduced a decent number of regressions and bugs, and waiting another 5 years for a bunch of one-line bug fixes that have already been committed seems unhealthy. Personally I've stopped running NUT on most of my machines because it's become too much of a hassle across different distros.

[jimklimov]

@awused : that's an interesting take... I'll ponder about it. Some of those issues got on the radar as regressions vs. 2.7.4 so there was an urge to finish them before 2.8.1. Hopefully there was substantial progress on those over summer to cut one soon.

As for almost-not-using NUT - my condolences, but not fully sure how that "hassle across different distros" (with many still shipping 2.7.4) is NUT project's fault. I get that having 2.8.1 released and packaged would help. And getting a healthy cadence of cutting releases surely is good. But then it is up to those distros, not NUT, for new code to take a week or a year to appear packaged/patched/whatever.

But to be frank, I'm biased - dealing with packaging and custom-rolled systems and forked FOSS to develop or operate stuff, I have no issue building code locally or making a package for local herd of machines. So plain did not realise something like this as a showstopper.

[awused]

Well, the problem for me is that they did update to 2.8.0, and 2.8.0 is just broken, 2.7.4 was working fine. If anything the fact that there are regressions from 2.7.4 is a reason to cut more releases, not to delay indefinitely. While I'm also comfortable building code locally, nut in particular has some weird issues I didn't care to figure out for what I assumed would be pretty quickly resolved. Had I known it was going to be well over a year for a one line change to get into a release I might have spent more time on it.

Even the one machine I bothered to locally patch the package on, a FreeBSD server, I only did because I was using nut before 2.8.0. Were I a new user and the software didn't work at all with my UPS, as 2.8.0 doesn't, I'd probably not have bothered.

[gdt]

I think 2.8.1 is now overdue. I would recommend going into freeze, bug fixes for regressions since 2.8.0 allowed, doc fixes allowed, call for testing, and try to get it out as soon as is practical without rushing, then return. It seems to me we have arrived at "people running 2.8.0 are behind and should upgrade".

This isn't a dup of "there shoudl be a plan". This is the separate "2.8.1 is overdue" issue.

[gdt]

As to Jim's comment about packaging system timelines: Sure, that's uncontrollable. But if there isn't a release, they can't possibly package it. And one there is a release, it's fair to tell users they have to submit bug reports against it. So don't worry about packaging timelines; you don't own that.