Review rules, the backlog, and a proposal for when nobody comes
Hello everyone,
CONTRIBUTING.md now follows the June conversation on this list — the rules from "The Next Release Is Within Reach" on 16 June, with the condition I added the next morning after the one objection. It also says what the GitHub ruleset really enforces, and on whom.
https://github.com/xymon-monitoring/xymon/blob/main/CONTRIBUTING.md
It is there because nobody objected in June, not because anyone agreed — say if you disagree and I will change it.
The backlog, measured: 53 ready for review (79 open, 26 of them drafts), median 20 days since being marked ready. Nothing is abandoned — none untouched for a fortnight — because I keep rebasing them. And the rate was never the problem: 60 merged between 9 August and 3 September, 51 of them with a review. Then it stopped. Nothing read or reviewed since 30 August, nothing merged since 3 September.
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)
The clock runs from when it was marked ready, and any review ends the wait — this is the fallback, not the path. Of the 53, 19 could go in today and the rest within two months with nobody doing anything.
The cost: two months means a feature can land unread. The bigger risk runs the other way — a project where finished work cannot move is one that stops.
None of it produces a reviewer or a contributor, and that is what we really need.
Let me know what you think!
Cheers
Bruno
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
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
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
Hi Nicola,
if my vote as an absent contributor counts:It counts for me! Of course, I would also be happy to see your C skills helping us solve some problems... but I know that's not always possible. Maybe later — no worries.
You have my +1 also on avoiding changes unsupervised/unreviewed by
human to hit the releaseYou know, my proposals are ideas, and it seems I'm wrong with some of them. That's perfectly fine with me and things are evolving.
I'm trying to push Xymon forward, using newer technology to make that revival possible. With my limited progarmming skills, much of what I've done simply would not have been possible without LLMs — they help a lot.
But we still need people with the right skills to review, correct, and improve that work. That's one of the challenges: Xymon stopped moving for a long time, and restarting it is difficult.
But I believe we can do it. That's why I'm putting effort into it — until Xymon can run by itself again.
So far, no code has been merged without human supervision/review: one person proposes or codes, and another reviews. That's good, and several of us have said that the code currently seems to be in good shape. Of course, none of this guarantees that we haven't introduced bugs.
I also agree that releasing often seems like a good idea!
The goal of the 4.3.31 milestone was to merge and upstream useful features and fixes from the different packagers, and simplify their work. I added Terabithia somewhat arbitrarily, following my instinct, but I'm completely open to comments. I'm still a novice in C and packaging, so I'm doing my best.
I went through Terabithia's ~200 commits, and as a result around 10 build/packaging PRs that were not originally expected are now in the 4.3.31 milestone. Some Terabithia work is already merged. We now have around 20 PRs waiting on the milestone, mainly covering critical issues and bug fixes, Terabithia features, and macOS problems.
My current thinking is:
All OSes are already supported when installing Xymon from source.
That's not a bad starting point.*
Terabithia is widely used, and it seems wrong not to offer RHEL
users something with the new release, even without full parity.*
Packages make upgrades easier and should help us find problems with
new releases more quickly.*
After seven years without a release, some changes are expected. I
would rather do the packaging/build changes now than repeat this
kind of work over several releases. Keeping RPM, Debian and FreeBSD
in sync may take time, especially as we are all volunteers.So I hear the argument for releasing more often. At the same time, I'm thinking about RHEL users and future packaging complications.
For now, unless convinced otherwise, I would let |xymon-rpm| try to fill the RHEL gap. In parallel, Roland (Debian) and Mark (FreeBSD) can digest the build/packaging PRs, tell us what they imply for their packages, and implement any necessary changes. I've tried to make the proposed changes concrete through the PRs, but ultimately they know their packaging better than we do. Of course, having more volunteers help them maintain this part would be nice, but that seems unlikely for now.
Since everyone is currently prepared to make some changes for a new release, this seems like a good time to get this work behind us.
Then future releases can hopefully be smaller and more frequent. Even one every two or three months would already be a new age for Xymon. :)
And shorter release cycles seem like a good idea to me: release as soon as it makes sense, perhaps even as soon as an important bug is fixed.
Also, if two of you decide that we should just make a release, that's perfectly fine with me!
And the good news is that Scot and Ralph have started testing |xymon-rpm|, so hopefully things will become clearer soon.
Bruno
Le 17.09.2026 à 10:40, Nicola a écrit :
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 <http://facebook.com/lazboy> |instagram.com/lazboy <https://instagram.com/lazboy> |youtube.com/lazboy <http://youtube.com/lazboy> 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
participants (4)
-
Bruno Manzoni
-
Nicola
-
Roland Rosenfeld
-
Scot Kreienkamp