The Next Release Is Within Reach
Hi guys,
We currently have 35 PRs that appear ready but are not being merged because nobody is reviewing them.
To make code review lighter, I propose modifying our governance as follows:
- Typos, comments, and documentation: no review required.
- Build/CI fixes: review optional.
- Test framework changes: review optional.
- Refactoring without behavior changes: review optional.
- Bug fixes: one review required before merge.
- New features: one review required before merge, with review encouraged at the start and during development when practical.
- Architectural changes: one review required before merge, with review encouraged at the start and during development when practical.
Let me know what you think.
Also, if someone could review PR #158 (normally the last remaining patch before all Debian and FreeBSD patches are integrated), I would appreciate it. For a new feature like this, I am particularly interested in feedback on:
- Whether the tests cover the expected use cases and edge cases.
- Whether the implementation is understandable and maintainable.
- Whether the user interface and behavior are intuitive.
- Any obvious issues, limitations, or potential improvements.
If everything goes well, a release could be expected fairly soon afterwards.
Thanks, Bruno
Hi Bruno!
On Tue, 16 Jun 2026, Bruno Manzoni via Xymon wrote:
To make code review lighter, I propose modifying our governance as follows:
- Refactoring without behavior changes: review optional.
I'm not sure whether this is a good idea. If the refactoring isn't minimal, there may be issues in the change. Especially if the refactoring is done by AI, which sometimes doesn't work as exact as it should do or changes things that don't have to do with the intended refactoring. This is also the reason for reviewing becoming so time intensive.
Greetings Roland
Hi Roland, Thanks for your feedback. You raise a very valid point regarding AI-generated code and large-scale refactoring. To address your concerns while still lightening our process, I propose splitting the rule into two separate cases based on risk, test coverage, and documentation:
1. Review Optional: For minor, manual refactorings—provided they are fully covered by tests AND(/OR?) clear evidence of validation is attached to the PR. 2. Review Mandatory: For major refactorings, AI-generated code, or any changes that lack full test coverage and structural evidence.
Does this compromise sound reasonable to you? Best regards, Bruno
Le 17.06.2026 à 08:48, Roland Rosenfeld a écrit :
Hi Bruno!
On Tue, 16 Jun 2026, Bruno Manzoni via Xymon wrote:
To make code review lighter, I propose modifying our governance as follows:
- Refactoring without behavior changes: review optional. I'm not sure whether this is a good idea. If the refactoring isn't minimal, there may be issues in the change. Especially if the refactoring is done by AI, which sometimes doesn't work as exact as it should do or changes things that don't have to do with the intended refactoring. This is also the reason for reviewing becoming so time intensive.
Greetings Roland
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Hi,
I'm not really a C-programmer but I will take a look at the PR's.
From other projects, I learned that a discord chat (or in an other app) is helpful to quickly get answers and feedback. Certainly in cases where there is a discussion or disagreement on how something should be implemented.
Stef
On 2026-06-16 23:24, Bruno Manzoni via Xymon wrote:
Hi guys,
We currently have 35 PRs that appear ready but are not being merged because nobody is reviewing them.
To make code review lighter, I propose modifying our governance as follows:
- Typos, comments, and documentation: no review required.
- Build/CI fixes: review optional.
- Test framework changes: review optional.
- Refactoring without behavior changes: review optional.
- Bug fixes: one review required before merge.
- New features: one review required before merge, with review encouraged at the start and during development when practical.
- Architectural changes: one review required before merge, with review encouraged at the start and during development when practical.
Let me know what you think.
Also, if someone could review PR #158 (normally the last remaining patch before all Debian and FreeBSD patches are integrated), I would appreciate it. For a new feature like this, I am particularly interested in feedback on:
- Whether the tests cover the expected use cases and edge cases.
- Whether the implementation is understandable and maintainable.
- Whether the user interface and behavior are intuitive.
- Any obvious issues, limitations, or potential improvements.
If everything goes well, a release could be expected fairly soon afterwards.
Thanks, Bruno
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Hi Stef, Here is the link to follow the chat: https://github.com/xymon-monitoring/xymon-problems/issues/1 (You should end up at: https://github.com/xymon-monitoring/private. Let me know if it works.) Thanks for reviewing the PR! Bruno
Le 17.06.2026 à 10:17, Stef Coene a écrit :
Hi,
I'm not really a C-programmer but I will take a look at the PR's.
From other projects, I learned that a discord chat (or in an other app) is helpful to quickly get answers and feedback. Certainly in cases where there is a discussion or disagreement on how something should be implemented.
Stef
On 2026-06-16 23:24, Bruno Manzoni via Xymon wrote:
Hi guys,
We currently have 35 PRs that appear ready but are not being merged because nobody is reviewing them.
To make code review lighter, I propose modifying our governance as follows:
* Typos, comments, and documentation: no review required. * Build/CI fixes: review optional. * Test framework changes: review optional. * Refactoring without behavior changes: review optional. * Bug fixes: one review required before merge. * New features: one review required before merge, with review encouraged at the start and during development when practical. * Architectural changes: one review required before merge, with review encouraged at the start and during development when practical.
Let me know what you think.
Also, if someone could review PR #158 (normally the last remaining patch before all Debian and FreeBSD patches are integrated), I would appreciate it. For a new feature like this, I am particularly interested in feedback on:
* Whether the tests cover the expected use cases and edge cases. * Whether the implementation is understandable and maintainable. * Whether the user interface and behavior are intuitive. * Any obvious issues, limitations, or potential improvements.
If everything goes well, a release could be expected fairly soon afterwards.
Thanks, Bruno
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
participants (3)
-
Bruno Manzoni
-
Roland Rosenfeld
-
Stef Coene