Hi, I just found this thread thanks to the mailing list archive UI: that's a great addition.
I agree (if my vote as an absent contributor counts) on the release more often proposal, but I wouldn't do it more than monthly for the time being, until we know enough people installs it as released, because we would miss bugs in a release and troubleshooting may become more difficult. You have my +1 also on avoiding changes unsupervised/unreviewed by human to hit the release
Nicola
Il giorno lun 14 set 2026 alle ore 19:55 Scot Kreienkamp via Xymon < xymon@xymon.com> ha scritto:
I would agree with Roland on releases. I would prefer to see monthly releases, or even weekly or daily if enough progress has been made. Why would anyone want large changesets on a single rollout, or wait weeks or months after a change is ready to be released?
Along those same lines what do you think about changing to a date-based release naming convention rather than the generic 4.x.x. Something like YYYY.MM.DD-#, or 2026-09-14-1 if it was the first release today. Seems like that would be easier than an arbitrary release number.
*Scot Kreienkamp | Principal Applications Infrastructure Architect | La-Z-Boy Incorporated * (734) 384-6403 | 1-734-915-1444 | Scot.Kreienkamp@la-z-boy.com One La-Z-Boy Drive | Monroe, Michigan 48162 | la-z-boy.com <http://www.la-z-boy.com/> facebook.com/lazboy | instagram.com/lazboy | youtube.com/lazboy
[image: LaZboy Logo]
-----Original Message----- From: Bruno Manzoni via Xymon <xymon@xymon.com> Sent: Monday, September 14, 2026 1:10 PM To: xymon@xymon.com Cc: Bruno Manzoni <bruno.manzoni@ubi-network.ch> Subject: [Xymon] Re: Review rules, the backlog, and a proposal for when nobody comes
Hi Roland!
Objection accepted, the delay is withdrawn. Nothing gets merged because a clock ran out.
On your future rule: the AI writes, a named human reads every line and answers for it. I think the current one should say it explicitly, because this can be fuzzy: the author supervises the AI and verifies in depth what it produces (that is what I try to do, not always successfully). But a second human review is still what makes the code good, because it catches what the first one missed.
I think your rule is where we will end up in the near future for one or two line fixes and very short code, which is where the LLM really performs. For anything more complex, what I have seen is that the generated code was always wrong, and unsupervised output was poor.
One main problem with the current rule is: how do I know the first human really went in depth? There is no way, at least for now, to tell good supervised code from bad unsupervised AI code.
And yes, your other idea is better than my proposal: release now. I will do it, not because I lead this project (I do not), only because the two of us agree — though yes, I do push it forward hard, in whatever direction I can.
What I was waiting for was a validated RPM build, so those users are not left with nothing, and a fix for some build problems on macOS. I will keep the macOS patch in the current milestone: having to patch my Mac and patch it back every time I want to test something is a real pain. I asked for help and hoped it would be quick. The rest can wait for the next release, so I will cut the milestone down to the absolute minimum I can work with. I also wanted to leave you and Mark some time. You say you are ready, so let us release.
I have never done one...
Cheers
Bruno
Le 14.09.2026 à 18:10, Roland Rosenfeld via Xymon a écrit :
Hi Bruno!
On Mo, 14 Sep 2026, Bruno Manzoni via Xymon wrote:
To resolve this I propose to add a delay before bypassing a PR:
- documentation, tests — 1 week (current 0 days)
- build and CI — 2 weeks (current 0 days)
- bug fixes — 1 month (current: never)
- everything else — 2 months (current: never) I object this proposal. I can live with AI generated code (don't like it, but accept it), but at least one human should review the changes. Maybe it's okay, if AI generates the change and you personally (not the AI, you are using) review the generated change.
I know, that I should review #219, but I'm currently on vacation, so I have not much time nor a big display nor a test environment, so I cannot review this big job. The review steps the AI did itself (finding some issues) shows that this isn't a trivial PR and reviewing it is important. I think that the review should include a end-to-end test on a real life system to see, whether this works as expected.
BTW: From my point of view, we should release early/often and the current snapshot is much better than 4.3.30 ever was. So why not just release 4.3.31 as is and continue to work on 4.3.32? If your AI stays as active as it currently is, we will never reach a state where no PRs for 4.3.31 are ready for review, since the AI generates them much faster than any human can review them.
Greetings Roland
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
