Thoughts on the new Xymon organization - feedback appreciated
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. *
- 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
My 2c on the next steps. I think we should move the IPv6 changes to a further version (5.0?) while using 4.4 as the "dropping compatibility" release to modernize the codebase and ease the maintenance. In the 4.4.x we could incorporate the encrypted/authenticated communication, which I think is a less impacting change. Reviving something like sleepycat (if I remember correctly the name), or a repo of useful plugins for particular monitoring types could be useful.
Sorry for being not much active recently (life and work impacted my available time)
Nicola
Il giorno gio 28 mag 2026 alle ore 08:56 Bruno Manzoni via Xymon < xymon@xymon.com> ha scritto:
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.
- 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.
- 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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Were you thinking of deadcat.net for plugins and things?? I don't know what happened to that, but there's another site called xymonton:
https://wiki.xymonton.org/doku.php/addons
Ralph Mitchell
On Thu, May 28, 2026, 8:12 AM Nicola <canne74@gmail.com> wrote:
My 2c on the next steps. I think we should move the IPv6 changes to a further version (5.0?) while using 4.4 as the "dropping compatibility" release to modernize the codebase and ease the maintenance. In the 4.4.x we could incorporate the encrypted/authenticated communication, which I think is a less impacting change. Reviving something like sleepycat (if I remember correctly the name), or a repo of useful plugins for particular monitoring types could be useful.
Sorry for being not much active recently (life and work impacted my available time)
Nicola
Il giorno gio 28 mag 2026 alle ore 08:56 Bruno Manzoni via Xymon < xymon@xymon.com> ha scritto:
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.
- 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.
- 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
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
Where do we want all of the documentation to end up?
On Thu, May 28, 2026 at 8:26 AM Ralph M <ralphmitchell@gmail.com> wrote:
Were you thinking of deadcat.net for plugins and things?? I don't know what happened to that, but there's another site called xymonton:
https://wiki.xymonton.org/doku.php/addons
Ralph Mitchell
On Thu, May 28, 2026, 8:12 AM Nicola <canne74@gmail.com> wrote:
My 2c on the next steps. I think we should move the IPv6 changes to a further version (5.0?) while using 4.4 as the "dropping compatibility" release to modernize the codebase and ease the maintenance. In the 4.4.x we could incorporate the encrypted/authenticated communication, which I think is a less impacting change. Reviving something like sleepycat (if I remember correctly the name), or a repo of useful plugins for particular monitoring types could be useful.
Sorry for being not much active recently (life and work impacted my available time)
Nicola
Il giorno gio 28 mag 2026 alle ore 08:56 Bruno Manzoni via Xymon < xymon@xymon.com> ha scritto:
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.
- 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.
- 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
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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Hi Josh, There's already a first take on this in the xymon-problems repo. See the documentation issue: https://github.com/xymon-monitoring/xymon-problems/issues/8
It's not new work: most of it was written back in 2023 and extracted from the mailing-list discussions I've just added a few things I came across since. So it may well be inaccurate or out of date. So treat it as a starting point, not a final answer.
Have a look and see what you think and if it answers some of your questions. Happy to help with any other questions (if I am able to), and if you'd like to change or add anything: I'll gladly help make it happen !
Bruno
Le 29.05.2026 à 17:36, Josh Luthman a écrit :
Where do we want all of the documentation to end up?
On Thu, May 28, 2026 at 8:26 AM Ralph M <ralphmitchell@gmail.com> wrote:
Were you thinking of deadcat.net <http://deadcat.net> for plugins and things?? I don't know what happened to that, but there's another site called xymonton: https://wiki.xymonton.org/doku.php/addons Ralph Mitchell On Thu, May 28, 2026, 8:12 AM Nicola <canne74@gmail.com> wrote: My 2c on the next steps. I think we should move the IPv6 changes to a further version (5.0?) while using 4.4 as the "dropping compatibility" release to modernize the codebase and ease the maintenance. In the 4.4.x we could incorporate the encrypted/authenticated communication, which I think is a less impacting change. Reviving something like sleepycat (if I remember correctly the name), or a repo of useful plugins for particular monitoring types could be useful. Sorry for being not much active recently (life and work impacted my available time) Nicola Il giorno gio 28 mag 2026 alle ore 08:56 Bruno Manzoni via Xymon <xymon@xymon.com> ha scritto: 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 _______________________________________________ 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 _______________________________________________ Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
On the initial post...
- documentation is still fragmented between SourceForge, mailing lists, distro patches, wiki pages, and GitHub discussions,
Is there anything that's on SF/patches/wiki pages that is NOT on the Github pages at this point? I am happy to help copy/paste/format to keep documents all in one place.
On Sat, May 30, 2026 at 6:18 AM Bruno Manzoni <bruno.manzoni@ubi-network.ch> wrote:
Hi Josh, There's already a first take on this in the xymon-problems repo. See the documentation issue: https://github.com/xymon-monitoring/xymon-problems/issues/8
It's not new work: most of it was written back in 2023 and extracted from the mailing-list discussions I've just added a few things I came across since. So it may well be inaccurate or out of date. So treat it as a starting point, not a final answer.
Have a look and see what you think and if it answers some of your questions. Happy to help with any other questions (if I am able to), and if you'd like to change or add anything: I'll gladly help make it happen !
Bruno Le 29.05.2026 à 17:36, Josh Luthman a écrit :
Where do we want all of the documentation to end up?
On Thu, May 28, 2026 at 8:26 AM Ralph M <ralphmitchell@gmail.com> wrote:
Were you thinking of deadcat.net for plugins and things?? I don't know what happened to that, but there's another site called xymonton:
https://wiki.xymonton.org/doku.php/addons
Ralph Mitchell
On Thu, May 28, 2026, 8:12 AM Nicola <canne74@gmail.com> wrote:
My 2c on the next steps. I think we should move the IPv6 changes to a further version (5.0?) while using 4.4 as the "dropping compatibility" release to modernize the codebase and ease the maintenance. In the 4.4.x we could incorporate the encrypted/authenticated communication, which I think is a less impacting change. Reviving something like sleepycat (if I remember correctly the name), or a repo of useful plugins for particular monitoring types could be useful.
Sorry for being not much active recently (life and work impacted my available time)
Nicola
Il giorno gio 28 mag 2026 alle ore 08:56 Bruno Manzoni via Xymon < xymon@xymon.com> ha scritto:
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.
- 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.
- 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
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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
Hi Josh,
I invited you to the organization.
Very little has been migrated so far. Most of what is on GitHub today is documentation that already lived in the source tree and moved with the code.
The current documentation is mostly reference material (man pages, configuration references, command help) and examples embedded in configuration templates.
Some gaps are:
Beginner tutorials*
Conceptual documentation*
Architecture documentationBefore migrating content from SourceForge, wiki pages, mailing lists, or other sources, I would prefer to first inventory what already exists, identify what is still relevant, and then decide what should be migrated, updated, reorganized, or retired.
I created the xymon-wiki repository to explore ideas and improvements, and we can use it to collect information and build a clearer picture of the current documentation landscape.
Of course, if you have other ideas or a different approach, I would be happy to discuss them.
Thanks for the offer to help. Let me know what aspect interests you most, and we can figure out together the most useful way to move things forward.
Regards,
Bruno
Le 30.05.2026 à 16:57, Josh Luthman a écrit :
On the initial post...
- documentation is still fragmented between SourceForge, mailing lists, distro patches, wiki pages, and GitHub discussions,
Is there anything that's on SF/patches/wiki pages that is NOT on the Github pages at this point? I am happy to help copy/paste/format to keep documents all in one place.
On Sat, May 30, 2026 at 6:18 AM Bruno Manzoni <bruno.manzoni@ubi-network.ch> wrote:
Hi Josh, There's already a first take on this in the xymon-problems repo. See the documentation issue: https://github.com/xymon-monitoring/xymon-problems/issues/8 It's not new work: most of it was written back in 2023 and extracted from the mailing-list discussions I've just added a few things I came across since. So it may well be inaccurate or out of date. So treat it as a starting point, not a final answer. Have a look and see what you think and if it answers some of your questions. Happy to help with any other questions (if I am able to), and if you'd like to change or add anything: I'll gladly help make it happen ! Bruno Le 29.05.2026 à 17:36, Josh Luthman a écrit :Where do we want all of the documentation to end up? On Thu, May 28, 2026 at 8:26 AM Ralph M <ralphmitchell@gmail.com> wrote: Were you thinking of deadcat.net <http://deadcat.net> for plugins and things?? I don't know what happened to that, but there's another site called xymonton: https://wiki.xymonton.org/doku.php/addons Ralph Mitchell On Thu, May 28, 2026, 8:12 AM Nicola <canne74@gmail.com> wrote: My 2c on the next steps. I think we should move the IPv6 changes to a further version (5.0?) while using 4.4 as the "dropping compatibility" release to modernize the codebase and ease the maintenance. In the 4.4.x we could incorporate the encrypted/authenticated communication, which I think is a less impacting change. Reviving something like sleepycat (if I remember correctly the name), or a repo of useful plugins for particular monitoring types could be useful. Sorry for being not much active recently (life and work impacted my available time) Nicola Il giorno gio 28 mag 2026 alle ore 08:56 Bruno Manzoni via Xymon <xymon@xymon.com> ha scritto: 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 _______________________________________________ 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 _______________________________________________ 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 toxymon-leave@xymon.com
It's really nice to see the effort that's being made. It's unfortunate that I'm going to be turning off the Xymon server at work in the very near future. We got bought by another company and they use LogicMonitor so Xymon is going.
I am seriously thinking about deploying it on a VM at home though to monitor my proxmox cluster and be able to get graphs for drive temps and such.
If I move job and they don't have something decent I'll be trying to get Xymon in again because as a Linux admin I find it an incredibly useful tool.
Thanks for all the efforts going on to get it progressing again and I look forward to hopefully suing it again in a future role and at the least probably using it at home.
I'm not sure how many years it is now but I think it's well over 10 years I've been using it. We started on 4.3.4 so it could well be 15 years.
Neil
Neil Simmonds
Senior Platform & Middleware Engineer (Unix)
[cid:fgfs_e04c0205-c635-4f54-817e-d1a70ae03721.jpg]
PHONE
0344 245 9200
ADDRESS
Unit A Brook Park East, NG20 8RY
Credit is provided by Frasers Group Financial Services Limited (Registered Company no. 00718151), which is authorised and regulated by the Financial Conduct Authority (FRN 311908) for consumer credit and general insurance and a member of the Finance and Leasing Association. Frasers Group Financial Services Limited is registered in England and its registered office is: Express House, Petre Road, Clayton Business Park, Accrington, Lancashire, BB5 5JB. For regulated payment services, Frasers Group Financial Services Limited is a payment agent of Transact Payments Limited, a company authorised and regulated by the Gibraltar Financial Services Commission as an electronic money institution. Transact Payments Limited, a company incorporated in Gibraltar (No 108217). Registered address 6.20 World Trade Center, 6 Bayside Road, Gibraltar, GX11 1AA.
Disclaimer | Frasers Group<https://frasers.group/legal/disclaimer>
From: Bruno Manzoni via Xymon <xymon@xymon.com> Sent: Thursday, May 28, 2026 08:56 To: xymon@xymon.com <xymon@xymon.com> Cc: Bruno Manzoni <bruno.manzoni@ubi-network.ch> Subject: [Xymon] Thoughts on the new Xymon organization - feedback appreciated
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.
- 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.
- 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.
- 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.
- 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
Hello. I'm very glad about all this activity to make Xymon live again. I have been using it since around 2006, and recently thinking about more modern alternatives, should ever development stop. But it's not! Thank you for your work and looking forward for a new release! I think that a modern UI is a feature that could expand users base. I read about a fork from a mailing list user (spiderr) and replied him inviting to join the development team. Hope that will be more and more improvements in our beloved software. Mario
Il giorno gio, 28/05/2026 alle 08.56 +0100, Bruno Manzoni via Xymon ha scritto:
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.
- 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.
- 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.
- 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.
- 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
Xymon mailing list -- xymon@xymon.com To unsubscribe send an email to xymon-leave@xymon.com
participants (6)
-
Bruno Manzoni
-
hopbyhop.net
-
Josh Luthman
-
Neil Simmonds
-
Nicola
-
Ralph M