The Next Release Is Within Reach

5 messages in this thread

list Bruno Manzoni · Tue, 16 Jun 2026 23:24:38 +0200 ·

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

list Roland Rosenfeld · Wed, 17 Jun 2026 08:48:21 +0200 ·

Hi Bruno!

▸ quoted from Bruno Manzoni


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

list Bruno Manzoni · Wed, 17 Jun 2026 09:38:54 +0200 ·

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

▸ quoted from Roland Rosenfeld


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

list Stef Coene · Wed, 17 Jun 2026 10:17:40 +0200 ·

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

▸ quoted from Bruno Manzoni


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

list Bruno Manzoni · Wed, 17 Jun 2026 10:43:55 +0200 ·

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

The Next Release Is Within Reach 🔗 link

The Next Release Is Within Reach