What are your thoughts regarding current and potential rsyslog support channels?
Overview
Traditionally the rsyslog community has sought and provided support through three main channels:
- mailing list
- forums
- ticketing system (at one time Bugzilla, now GitHub)
Over the years, the community support options have shifted to the point that we are considering retiring the forums in order to best direct users that post there to other, more current options that better fit their needs. It would appear that aside from specific cases, the time of the web forum has passed.
That said, we would like to get your feedback to best determine the way to move forward. What follows are some initial ideas to get the conversation started. Please feel free to respond here, via Twitter, the mailing list or on GitHub. Thank you for your time.
Potential Support options
The following items are all “whiteboard” topics, listed in no real order in an effort to start discussion. Neither the order or presence in the list indicates that a decision has already been made by the team to pursue the support option. Please feel free to suggest your own entries.
Keep the forums, send notifications of new posts made on the forums to the mailing list
- Note: Attempts to respond to those notifications would not result in the replies being posted to the original topic on the forums.
- Would this truly result in any additional responses to those forum posts than are currently being provided now?
Set forums to read-only, direct visitors to GitHub for support
Set forums to read-only, direct visitors to StackOverflow
It would appear there is already solid participation there for questions tagged with rsyslog:
https://stackoverflow.com/questions/tagged/rsyslog
Official Twitter presence
followers are encouraged to retweet rsyslog related questions, guides, etc to their followers.
This is actually a “trick” entry of sorts! We already have a Twitter account that you can follow and interact with: @rsyslog
- Do you already follow that account?
- Would you retweet content from others?
- Would you respond to help requests that are retweeted
- If links to active GitHub issues are posted, will you take the time to go view them?
Official Facebook presence
Would you participate in discussions and support requests made there?
IRC, XMPP, Slack, …
- Would you participate?
- Do you feel this could replace the forums?
- Would this be more useful to you than the mailing list?
Version support policy change
We will be changing our policy so that only the latest stable build will be officially supported. This is done in an effort to concentrate resouces on building new and great things, instead of wasting a lot of time merging from old versions. A lot of -competing- projects have this policy and thus can move faster. We don’t want to carry that disadvantage any further with us.
For folks with support contracts, of course nothing changes: we always supported all versions – no matter how old – under these contracts (as long as technically possible). Please also note that we always consider older, but frequently used versions when it comes to important bug fixes (for example, I lately added a couple of fixes to v5.10, which is no longer officially supported for quite a while).
I would like to point out that rsyslog has a very considerate version management, with keeping major versions in different branches and (via professional support) taking care of each old version. This enterprise release scheme is under no discussion.
As a side-note: the discussion was started when I thought about non-critical fixes that I did for v7 and we thought about if it really makes sense to spend time to backport them to v6. There are also some enhancement-like “bugfixes” (like better config error messages), which will stay with the devel branch and mature into the next stable (if for nothing else, than for their regression potential).
Best regards,
Rainer Gerhards
legacy options support
Via the compatibility mode option (-c), rsyslog still supports legacy options (like -t to start a tcp listener). This code complicates a couple of things quite a bit, especially in regard to the config system.
We are very tempted to drop support for legacy options in v6. That could lead to smaller and simpler code. Also, we think it is acceptable that someone running v6 finally moves away from the sysklogd/rsyslog v1 style of configuration via command line options.
We also noticed that the average user seems to have problems identifying where each distro places the actual call to rsyslogd, so users seem to prefer configuring all options inside the main configuration file (what we tend to think to be more useful as well).
Does anyone has a good argument why to retain the legacy support in v6? If so,please make yourself heard, because otherwise we’ll probably drop that support.
Best regards,
Rainer Gerhards