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
facebook.com/lazboy  | instagram.com/lazboy | youtube.com/lazboy

-----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