Hi all,
First of all, many thanks to everyone involved in the new Xymon
organization and the recent work around the project. A lot of effort has
clearly gone into modernizing and stabilizing the codebase while still
preserving the spirit and simplicity of Xymon.
*
1. The new governance model is a very positive step for the project:*
The fact that *at least two people are now involved in validating and
merging changes* *gives much more legitimacy and long-term stability to
the project. *It certainly *slows things down a bit*, but for
infrastructure software this is probably the correct tradeoff.*It
reduces the risk of unilateral decisions and helps keep the technical
direction coherent.*
*2. The modernization effort* is also going *in the right direction*.
One major goal of the new organization is bringing Xymon back to a
stable and maintainable upstream state, while progressively
*reintegrating improvements that historically existed only in downstream
FreeBSD and Debian repositories *(and some in the 4.4 alpha branch).*
*
*The work achieved so far in this direction is very encouraging. Several
important steps have already been achieved:*
- GitHub Actions now automatically builds and validates Xymon across
multiple platforms,
- many Linux, FreeBSD, NetBSD, and pkgsrc portability and build issues
were fixed upstream,
- parser cleanup and hardening improved robustness,
- several memory leaks and stability issues were corrected.
As many changes have already been completed, the project is
progressively moving toward a new “ready to release” phase, with a
growing number of downstream fixes already consolidated upstream, even
if the work is not fully completed yet.*It may be better to iterate
additional fixes in future releases *instead of trying to consolidate
everything at once.
This first release will also impact Roland and Mark as Debian and
FreeBSD maintainers, so*it should happen when they feel ready,* as they
will also need to prepare and publish updated versions on their side.
*Keeping the current focus on reducing historical technical debt and
reintegrating long-standing downstream work upstream still appears to be
the correct priority for now.*
*3. That said, there are still some weak points:*
- *documentation is still fragmented* between SourceForge, mailing
lists, distro patches, wiki pages, and GitHub discussions,
- *the maintainer pool is still relatively small,* which can slow
reviews and create some continuity risk,
- and the project still lacks a clearly centralized long-term roadmap
defining modernization priorities and release direction.
Overall though, the direction feels healthy, pragmatic, and technically
credible.
*
4. It would be very interesting to hear what you think as well:
*- What could still be improved?
- What is currently missing?
- How could more people become involved?
- And what should the priorities be for the next phases of the project?
Bruno