Every know and then somebody asks what “release schedule” I have on my mind for future rsyslog releases. Today, it happened again, so I’ll do my usual blog post ;). Long time readers of this blog will know that this is a snapshot of what I have on my mind – open source development is quite dynamic and so what I actually implement can be quite different – and has been so in the past. It may be a good time to read my blog post describing how I assign priorities to rsyslog work.
For the foreseeable future, I have two primary things on my mind: one is a set of tools to gain insight knowledge of rsyslog’s inner workings while it is running. This includes statistics, but goes beyond (still, a recent forum post on rsyslog statistics may be an interesting read). This feature is of interest for the community at large, but it is also something that I need to do some in-depth performance analysis plus it is a real great debugging helper. As such, I intend not only to provide the glue inside rsyslog, but also create a full-blown GUI so that the power can actually be used. If nothing comes in the way, this is my top priority for new work (I intended to begin with it during summer time, but then more important things came into its way – but now it is becoming really pressing…).
The next feature I have on my mind is a change to the configuration language, which may also include some core changes. The community complains rightfully that rsyslog’s configuration is a real pain. It is extremely hard to configure some of the most enhanced features – even I need to think hard about how to create some desired results. This is a result of the growth of rsyslog. When the current config system was invented (some three years ago?), we had a handful of low-power commands. This has dramatically changed. For some time, I intended to replace the config language solely by a scripting language. This I no longer believe in. A full-blown scripting language would be a very desirable enhancement, but the base configuration must be done without it (this is also a performance issue). Redoing the config language includes untangling some of the inner workings, adding more flexibility. I am working towards that goal for roughly two and a half month now and that part went well. Now I need to do the next step. I expect that a new config format requires at least a month, more realistic two, to materialize. But adding more features with the current config system is of limited use, because only “expert experts” could configure them. But while the config is important, it is on the second spot on my todo list, right after the GUI and diagnostics tools.
GUI and diagnostics I expect another at least two month to get to something decent. Adding these numbers, I really do not think what the next larger features could be that I intend to implement. If all goes well, I can think about this in spring.
Also, I am currently quite busy with some other, paid, projects. So the time I can spent on rsyslog at the moment is limited. I devote much of this time to fixing bugs, with a primary goal being to get v5 finally ready for prime time (it looks good, but we are not yet fully there).
Also, I notice that adoption rate increases. I notice that by a large growth in support requests both on the mailing list as well as the forum. This is good new, but the bad news is that there are only few frequent contributors. So there is a lot of things that I need to take care of myself, and this needs increasingly more time – time that I obviously do not have for bug-fixing or developing new features. To get things a bit balanced, I have stopped responding to some questions, those that I think either a little google search can lead results to or those that obviously have a primarily commercial background. I’d like to respond to anything – but unfortunately, I simply do not have the time (if I did, rsyslog development would be totally stalled).
As I said, this is just a snapshot of how things look. Maybe tomorrow a sponsor shows up that changes my todo list considerably (we had only very few occurrences of such, but we thankfully had ;)). Even with a sponsor, I am tied with work for the rest of this year, then I have a little vacation, some more paid work, so that I think I can begin working on larger features mid-January, maybe a bit later. Bottom line: don’t take any “schedule” for granted, but I hope you get an overall idea of how things evolve. And: please continue to send in bug reports and feature request. Feature requests are very important – I use them (and their occurrence rate!) to judge how much demand for a feature there is in the community.
Happy syslogging!