On Fri, 8 Mar 2019 at 15:09, Axel Beckert <user-bc188e45dae4@xymon.invalid> 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, Axel
And 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