Today we released our first bug fix release after the 1.0 in February.
There is one bug fixed which made the debian packages from the 1.0 look
like 0.9 packages. The other bugs are related to the
Summer vacation is over and we are making good progress on the way to a stable 1.0 release which is planned for the next weeks. A change to make timeperiods more sane and some final testing are hopefully done till the weekend.
Till the final release, you can test the daily releases which are almost exactly like the stable release, the only different part is the version string.
Also last news call to help reviewing a few last documentation pages is still valid.
One last note, Andreas will talk about Naemon on the OSMC in Nuremberg this year.
Since we started the documentation project, we made great progress. Mostly due to the help of Johan. Thanks.
The initial import of the original documentation pages has been finished, but there are still pages left to be reviewed. This can be done by anyone who wants to help making our documentation awesome. Just follow the steps as described here.
All pages left over for review got a review_required tag at the top of the page so they can easily be found. A simple grep would also work:
%> grep -r review_required documentation/usersguide/
The doxygen documentation has already been ported into the website and is now part of the normal developer documentation.
We now even have Travis CI tests for our website.
Next steps are:
Almost half a year after we started this project we can now announce the first release.
The version 0.8.0 is a stable release, which means it does not contain any known critical issues. It’s not a 1.x release yet because we felt like it’s a good idea to be able to change APIs before a final 1.x release. That said, the 0.8.0 is probably lot more stable than its predecessor.
We tried to make getting started as easy and convenient as possible, so there are binary downloads for common linux systems and source rpms available. Unless you have good reasons, you really should go for the binary releases - they are build to just work.
We spend a lot of time to build tests and fix the most critical bugs of Nagios 4. There is a list of active issues in the known issues page. It’s not yet completed and we have to walk through all issues and decide whether Naemon is affected or not.
Naemon is a community project. So if you like this project, talk about it - or even better, help make it better. See the community page on how you can help.
Today we started the documentation project and you are welcome to help out. There is lot of stuff to write and the more people help, the less documentation has to be written by single person.
The issues with our build system have been sorted out and it seems quite stable and we only have to tweak some last things, like better init scripts, before we finally release the first version of Naemon.
We’re still working on getting a release out - unfortunately, we’ve been having some issues with our build system.
But we do have a new webpage - how about that?
One of our frustrations with Nagios is that while it does have a lot of tests, very few of them actually pass. That’s OK, though, because they’re executed very rarely.
Our plans for the future involve quite a bit of rewriting things behind the scenes, without any of our users noticing it. This is absolutely impossible to do without a much more serious QA effort.
Every night, the awesome Consol build cluster creates nightly packages for our primary platforms, and runs tests on them. There are currently 13 different OSes with two arches each, adding up to 26 different builds. As they also build binary packages, this makes it easy for others to do further testing. The whole process takes hours
But hours every night isn’t acceptable. We also need a modern CI system, with near-instant feedback on changes, which we have, thanks to travis. Several different core suites, as well as a few overall suites, are run per commit. This notifies us as soon as a test breaks and keeps quality and testing at the top of our minds.
While we have a lot of untested code today, going forward, there’s no reason for you not to include tests in your pull requests.