On Fri, 8 Mar 2019 at 15:09, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions.
I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.
Yes, you're quite right, I meant CVS. I must have been having a mental blank or typoed.
Git, specifically GitHub, has replaced SVN as the best thing to promote community contributions, and I think it would be beneficial if the official Xymon code repos are migrated to GitHub.
Definitely, but it's also not the only thing which is needed for getting contributions from external contributors. It's also a social thing.
Reviewing and accepting contributions — or maybe even giving trustworthy contributors commit access is also necessary for a FLOSS project. But as far as I can tell, this happens in the Xymon project, although not on a daily base.
I would say it has happened, but not very consistently, especially recently. There have been patches submitted via the mailing list that got missed by the maintainers, there are probably still a bunch outstanding. GitHub might make these more obvious. Beyond this, I totally agree with your comments.
but github would allow the community to report issues,
SF does allow that, too, it's just not enabled for the Xymon project on SF. Example of an SF project where it is enabled: https://sourceforge.net/p/nfsen/bugs/
provide updates/patches via pull requests,
Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/
and download either released versions via the tags
Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27
if necessary or the latest code via the 'develop' (or whatever) branch.
https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk
Don't get me wrong: I think SF degraded from once the best place to host FLOSS to a website with tons of outdated trash and the most horrible UI I ever saw from a code hosting site. Not to mention that it is far too overladen with ads and popup.
My personal preference in VCS hosters is also GitHub as — from my point of view — they currently provide the best user experience. OTOH there might be some qualms about Github being not completely open source and being owned by Microsoft.
Well another option is just to convert the repo on SF from SVN to Git, but keep it hosted on SF. And then also to enable the bugs and patches area - if someone is going to monitor and maintain those areas. I have seen SF projects where no-one does. But most active FLOSS projects are on GitHub these days.
And with regards to being dead or not: Development greatly sped up when J.C. Cleaver took over release management, but it indeed seems to have stalled a little bit again. Then again, IIRC J.C. mostly took over release management so that Henrik can focus on long-time development. And if there is not much to fix in the current stable releases, not having a stable release every few months is not necessarily "dead", but might also be "stable, no relevant open issues".
Yes, development did greatly speed up, but it practically ceased when J.C., I think, found difficulty merging the patches he had been using in his RPMs with Henrik's new 4.4 code. Or over 2 years ago (Jan 2016) when he released 4.3.28. I know the idea was that Henrik could focus on long-time development, but I think that ceased over 3 years ago - his last commit was in Jan 2016, with the last development type commit being Dec 2015. Both of them changed jobs (Henrik in Aug 2013 and J.C. in Sep 2015) and I'm guessing no longer used, or needed to develop, Xymon in their new roles and then their desire or capacity to keep putting time into the project dwindled.
(And yes, I'm still hoping and waiting for IPv6 support, too, especially in xymonnet-based checks. Reporting to IPv6-only servers is no issue though, if you anyways use stunnel to encrypt the client-reporting traffic.)
Kind regards, AxelAnd I'm still hoping for TLS support in the client. I did try https URL as the recipient (which should work - r7797) but I couldn't get it to work in the RPM version.
Kind regards,
SebA