NUT master-branch builds broken after recent PRs and/or infra changes about nut HOT 7 CLOSED

All apologies again if I sound disrespectful, too tired, too... too many things :D
Slackware was my 1rst Linux, back in 1995. It made me fall in Love with Free Software!
All due thanks and respect for your work :)
And be assured that I won't bullsh*t NUT after soooo many 1000s hours spent to make what it is :)

Again, take look at SmartNUT, despite just starting to (re)shape it, you should understand why this idea is exciting me as my 1rst Slackware, first contrib, first time I met NUT, ... ;)
@jimklimov can say he already saw me doing that exact same, 15 years ago. But the landscape was not ready. Now it is...
And if you're interested in, I always need help to make my ideas come to life faster :D not just coding, any help

from nut.

I'm aware I'm not really entitled to an opinion here not having contributed all that much code-wise... but personally not really all that happy with the fast-paced pushing to the master at the moment, perhaps we can go back to tested and CI-approved pull requests as an ideal standard for keeping such bugs making their way into master on a minimum.

On another note I think we should stick to the principle of least surprise where possible as far as changes to crucial parts of the machinery are concerned. Perhaps also some proposed changes to nut-scanner warrant some more discussion here (regarding dropping parameters, structural changes, expected outputs). Don't want to step on anyone's toes here, happy for all the active development too, just my opinion from my perspective or rather gut-feeling there.

from nut.

sorry for being pushy here. Wanted to see my new SmartNUT pet peeve coming to life fast, and the future on NUT main orientation (Linux more than OpenIndiana, though no underestimation) along... which I started long before retiring...
As a retired back to OSS a bit, I don't have anymore the whole chain (upstream-Debian...) in control, which is destabilizing :D
I agree with your PoV @desertwitch. that the end result (NUT release) must be clean! Sorry if it sounded disrespectful over @jimklimov's work on the CI.

As an explanation: as the main useful NUT code producer (usbhid-ups, snmp-ups, dummy-ups, Debian package; nut-scanner, ...), despite retired, I'm still more, in favor of having 80% happy first and fast ;) A CI blocking for OpenIndiana over development is to me a concern! It should block for the release obviously, but not slow innovation. In Debian ,there are priorities on the ports.
That's how I made all this. I'm all for CI, it's the main part of my daily job. But let's not more royalist than the King ;)

The whole world is not Linux box indeed, and you should know I've been fighting for that.
But it's 80% of the users use Linux (through whichever methods, like Home Assistant), and I always first satisfy this part before the next ;) for 3 decades now!
I'd say to close that "what makes the world moving is not CI, but code. CI helps to improve code, but it doesn't make it" ;)
PR welcome again... if you're faster than me :)

from nut.

My concern was towards the master branch, not necessarily only the releases. I think a lot of people have become used to building NUT from master and things being relatively stable and structured there (no real surprises due to Jim's very careful considerations and his principles of least surprise regarding changes). Also particularly thanks to what some may consider as a overly strict CI testing process before actual merging of new pull requests. This was further fueled by the relatively long gap between 2.8.0 and 2.8.1 releases, so a lot of people probably have become used to this project flow and relying on the stability of the master branch over the last two years - I myself have at least. It's a pity if this were to change without further notice (is my personal opinion), because this - to me - is what really makes NUT stand out... it just works everywhere and doesn't break even between builds (for the most part). Being able to rely on the essential functions not changing substantially, to the point where I as end-user need to start reading manuals again, was the icing on the cake there. And more fast-paced working in separate branches, but not on master, shouldn't really slow innovation all that much - with all due respect to your previous contributions.

And please don't get this as disrespect or the wrong way overall, I'm not at all against innovations and PRs. My perspective building on Slackware is probably also entirely different from yours, I just think it'd be unfair towards those not reading here if the master branch were to become suddenly and unnecessarily destabilized (as compared to the flow of the last two years) by premature-ish PR merges or direct experimental-ish code on the master branch when there's other ways to introduce new code while preserving the overall flow and stability of the project these past years.

Let's wait what @jimklimov says... :-)

from nut.

you're right about master. And the PR was scheduled. Just not the best timeframe...

So better act than say ;) That's again how I build (or help to) NUT and its many integrations and deployments

And just to be clear: these "premature PRs fast merged" are well working / heavily tested code, improving NUT integration ability, and with extensive UT and real-life smoke tests. As I always did ;)
It just doesn't build on some venerable (not to say lagging behind the pack) systems. Which needs to be fixed. But with lower priority to me.

So again, better code than words to make NUT moving (and in the right direction), PRs is out and should fix... Otherwise, as usual, I'll take care.
Merry xmas to those celebrating today (back in a week @jimklimov ;))

@desertwitch I encourage you to read about SmartNUT https://github.com/networkupstools/nut/projects?type=classic ;)
And possibly about the extent of my "previous contribs" ;) with all respect.
And the detailed results of the CI: https://ci.networkupstools.org/job/nut/job/nut/job/PR-2251/1/pipeline-graph/
(I did not broke the world really :D)
Sorry if it sounds impolite, I'm possibly too tired and not having fun (and recognition) coding opensource as before.

from nut.

@aquette Thanks for your response and perspective, it's much appreciated. I just wanted to put my personal opinion here (building and packaging on Slackware as one of the less commonly used OSes these days), with the utmost respect to your many contributions which shaped NUT into the project it is today - hell, my UPS wouldn't even have a driver without your efforts. And my opinion is just that, a single user's opinion, so do take it or leave it. Happy holidays and thanks again!! 😄

from nut.

I think I found the OI issue - the migrated NUT CI controller pinged back to the original VM while it's alive to use as a build node, but got into a wrong container's ssh port.

from nut.