Mailing List Archive

rsyslog version numbering change
Hi all,

as you know, rsyslog uses a version number scheme of

8.<real-version>.0

where we increment <real-version> every 6 weeks with each release. The
8 and 0 are constant (well, the 0 could change to 1 with a very
important patch, but in practice we have only done this once).

While this scheme has worked pretty well since we introduced it, I
often see people not understanding that there is really a big
difference between 8.24 and e.g. 8.40. Looking at recent trends in
software versioning, we see

a) single-number versions, e.g. in systemd
This is actually what we use, except that we make it look like
and old-style version number by the prefix 8 and suffix 0.
b) date-based versions, e.g. by distros (Ubuntu 18.04)

I would like to make a bold move and change rsyslog's version to

yyyy.mm.dd

of the actual release date. That makes it crystal-clear how old a
version is and also removes any ambiguity between daily builds and
official releases. Bug fix releases can also be easily done as we
never ever had two of them at the same day.

That means the next releases would not be
8.41.0 and 8.42.0 but rather 2019.01.22 and 2019.03.05.

A drawback of the change is that possible enterprise distributions
will not package any 2019+ releases until their next major release,
but I would be willing to accept this in preference of better clarity
for the user.

If there is no hard objection, I'll change the version scheme with 2019.01.22.

Any concerns please let me know.

Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
Agree. We did this several years ago for exactly the same reasons.

Regards,


On 12/15/18 6:19 AM, Rainer Gerhards wrote:
> Hi all,
>
> as you know, rsyslog uses a version number scheme of
>
> 8.<real-version>.0
>
> where we increment <real-version> every 6 weeks with each release. The
> 8 and 0 are constant (well, the 0 could change to 1 with a very
> important patch, but in practice we have only done this once).
>
> While this scheme has worked pretty well since we introduced it, I
> often see people not understanding that there is really a big
> difference between 8.24 and e.g. 8.40. Looking at recent trends in
> software versioning, we see
>
> a) single-number versions, e.g. in systemd
> This is actually what we use, except that we make it look like
> and old-style version number by the prefix 8 and suffix 0.
> b) date-based versions, e.g. by distros (Ubuntu 18.04)
>
> I would like to make a bold move and change rsyslog's version to
>
> yyyy.mm.dd
>
> of the actual release date. That makes it crystal-clear how old a
> version is and also removes any ambiguity between daily builds and
> official releases. Bug fix releases can also be easily done as we
> never ever had two of them at the same day.
>
> That means the next releases would not be
> 8.41.0 and 8.42.0 but rather 2019.01.22 and 2019.03.05.
>
> A drawback of the change is that possible enterprise distributions
> will not package any 2019+ releases until their next major release,
> but I would be willing to accept this in preference of better clarity
> for the user.
>
> If there is no hard objection, I'll change the version scheme with 2019.01.22.
>
> Any concerns please let me know.
>
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.


_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
Am Sa., 15. Dez. 2018 um 13:20 Uhr schrieb Rainer Gerhards
<rgerhards@hq.adiscon.com>:
> Any concerns please let me know.

Maybe interesting to you https://joeyh.name/blog/entry/version_numbers/

This would translate to 8.YYYYMMDD in your case.

Has the additional benefit, that should you decide to re-architect
rsyslog in a significant way, you can use
9.YYYYMMDD

If there is such a potential significant change in the future, there
is some value to it, if a user can quickly see this.

Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
Am Sa., 15. Dez. 2018 um 15:02 Uhr schrieb Michael Biebl <mbiebl@gmail.com>:
>
> Am Sa., 15. Dez. 2018 um 13:20 Uhr schrieb Rainer Gerhards
> <rgerhards@hq.adiscon.com>:
> > Any concerns please let me know.
>
> Maybe interesting to you https://joeyh.name/blog/entry/version_numbers/
>
> This would translate to 8.YYYYMMDD in your case.
>
> Has the additional benefit, that should you decide to re-architect
> rsyslog in a significant way, you can use
> 9.YYYYMMDD
>
> If there is such a potential significant change in the future, there
> is some value to it, if a user can quickly see this.

One other benefit of keeping the 8. prefix would be, that should you
ever decide to change the versioning scheme again, you haven't burned
all version numbers up to 2018.


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
El sáb., 15 dic. 2018 a las 17:05, Michael Biebl via rsyslog
(<rsyslog@lists.adiscon.com>) escribió:
>
> Am Sa., 15. Dez. 2018 um 15:02 Uhr schrieb Michael Biebl <mbiebl@gmail.com>:
> >
> > Am Sa., 15. Dez. 2018 um 13:20 Uhr schrieb Rainer Gerhards
> > <rgerhards@hq.adiscon.com>:
> > > Any concerns please let me know.
> >
> > Maybe interesting to you https://joeyh.name/blog/entry/version_numbers/
> >
> > This would translate to 8.YYYYMMDD in your case.
> >
> > Has the additional benefit, that should you decide to re-architect
> > rsyslog in a significant way, you can use
> > 9.YYYYMMDD
> >
> > If there is such a potential significant change in the future, there
> > is some value to it, if a user can quickly see this.
>
> One other benefit of keeping the 8. prefix would be, that should you
> ever decide to change the versioning scheme again, you haven't burned
> all version numbers up to 2018.

That's indeed a very good argument. To avoid the long version string
we could also go 2-digit years and bump the "major" version on next
century change ;-)

Thx for the feedback so far!
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
FWIW, I think that semantic versioning could be used here, provided that you are willing to progress past 8.x, which this proposal clearly indicates you are willing to do.

I think many users have learned (or are learning) that the first number indicates the potential for major behaviorial changes, so moving past 8.x will be the first indicator that whatever they are using is behind the latest upstream release.


------ Original message------
From: Rainer Gerhards
Date: Sat, Dec 15, 2018 6:20 AM
To: rsyslog-users;
Cc:
Subject:[rsyslog] rsyslog version numbering change

Hi all,

as you know, rsyslog uses a version number scheme of

8.<real-version>.0

where we increment <real-version> every 6 weeks with each release. The
8 and 0 are constant (well, the 0 could change to 1 with a very
important patch, but in practice we have only done this once).

While this scheme has worked pretty well since we introduced it, I
often see people not understanding that there is really a big
difference between 8.24 and e.g. 8.40. Looking at recent trends in
software versioning, we see

a) single-number versions, e.g. in systemd
This is actually what we use, except that we make it look like
and old-style version number by the prefix 8 and suffix 0.
b) date-based versions, e.g. by distros (Ubuntu 18.04)

I would like to make a bold move and change rsyslog's version to

yyyy.mm.dd

of the actual release date. That makes it crystal-clear how old a
version is and also removes any ambiguity between daily builds and
official releases. Bug fix releases can also be easily done as we
never ever had two of them at the same day.

That means the next releases would not be
8.41.0 and 8.42.0 but rather 2019.01.22 and 2019.03.05.

A drawback of the change is that possible enterprise distributions
will not package any 2019+ releases until their next major release,
but I would be willing to accept this in preference of better clarity
for the user.

If there is no hard objection, I'll change the version scheme with 2019.01.22.

Any concerns please let me know.

Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
El sáb., 15 dic. 2018 a las 17:58, Adam Chalkley
(<atc0005@auburn.edu>) escribió:
>
> FWIW, I think that semantic versioning could be used here, provided that you are willing to progress past 8.x, which this proposal clearly indicates you are willing to do.

Well, actually we moved away from that with the last change.

background info:
https://www.slideshare.net/rainergerhards1/rsyslog-version-naming-v860
>
> I think many users have learned (or are learning) that the first number indicates the potential for major behaviorial changes, so moving past 8.x will be the first indicator that whatever they are using is behind the latest upstream release.

That's a main backdrop when it comes to distros: once the major
version is bumped, you can be sure the package will not be updated
until their next major release, which can mean 2 to 3 years. Sticking
with the perfix "8." solved that issue ;-) I assume an obvious date
part in the version will also solve that issue.

There is also one other thing to consider: it is rsyslog philosophy to
NEVER break existing configurations. If I apply the "API" thoughs of
semantic versioning to this non-API world, that actually means we
should never bump the major version -- which is exactly what we do not
longer do since 2014.

Michael's suggesting of sticking with the "8." prefix makes a lot of
sense in regard to these two points as well.

Rainer
PS: in an ideal world, semantic versioning is really the route to
take. In the real world it does not work any longer :-(

>
>
> ------ Original message------
> From: Rainer Gerhards
> Date: Sat, Dec 15, 2018 6:20 AM
> To: rsyslog-users;
> Cc:
> Subject:[rsyslog] rsyslog version numbering change
>
> Hi all,
>
> as you know, rsyslog uses a version number scheme of
>
> 8.<real-version>.0
>
> where we increment <real-version> every 6 weeks with each release. The
> 8 and 0 are constant (well, the 0 could change to 1 with a very
> important patch, but in practice we have only done this once).
>
> While this scheme has worked pretty well since we introduced it, I
> often see people not understanding that there is really a big
> difference between 8.24 and e.g. 8.40. Looking at recent trends in
> software versioning, we see
>
> a) single-number versions, e.g. in systemd
> This is actually what we use, except that we make it look like
> and old-style version number by the prefix 8 and suffix 0.
> b) date-based versions, e.g. by distros (Ubuntu 18.04)
>
> I would like to make a bold move and change rsyslog's version to
>
> yyyy.mm.dd
>
> of the actual release date. That makes it crystal-clear how old a
> version is and also removes any ambiguity between daily builds and
> official releases. Bug fix releases can also be easily done as we
> never ever had two of them at the same day.
>
> That means the next releases would not be
> 8.41.0 and 8.42.0 but rather 2019.01.22 and 2019.03.05.
>
> A drawback of the change is that possible enterprise distributions
> will not package any 2019+ releases until their next major release,
> but I would be willing to accept this in preference of better clarity
> for the user.
>
> If there is no hard objection, I'll change the version scheme with 2019.01.22.
>
> Any concerns please let me know.
>
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
sounds like a good idea.
Enterprise distros are always behind, this won't stop them from updating any
more than they already do, and will make it clear how old it is.

Just as a note, if there is a same-day bugfix, just post-date it (use the next
day's date), that will only cause problems if there is a long series of
one-a-day-or-more bugfixes, and if that happens, we have far bigger problems
than the version number. :-)

David Lang

On Sat, 15 Dec 2018, Rainer Gerhards wrote:

> Date: Sat, 15 Dec 2018 13:19:33 +0100
> From: Rainer Gerhards <rgerhards@hq.adiscon.com>
> Reply-To: rsyslog-users <rsyslog@lists.adiscon.com>
> To: rsyslog-users <rsyslog@lists.adiscon.com>
> Subject: [rsyslog] rsyslog version numbering change
>
> Hi all,
>
> as you know, rsyslog uses a version number scheme of
>
> 8.<real-version>.0
>
> where we increment <real-version> every 6 weeks with each release. The
> 8 and 0 are constant (well, the 0 could change to 1 with a very
> important patch, but in practice we have only done this once).
>
> While this scheme has worked pretty well since we introduced it, I
> often see people not understanding that there is really a big
> difference between 8.24 and e.g. 8.40. Looking at recent trends in
> software versioning, we see
>
> a) single-number versions, e.g. in systemd
> This is actually what we use, except that we make it look like
> and old-style version number by the prefix 8 and suffix 0.
> b) date-based versions, e.g. by distros (Ubuntu 18.04)
>
> I would like to make a bold move and change rsyslog's version to
>
> yyyy.mm.dd
>
> of the actual release date. That makes it crystal-clear how old a
> version is and also removes any ambiguity between daily builds and
> official releases. Bug fix releases can also be easily done as we
> never ever had two of them at the same day.
>
> That means the next releases would not be
> 8.41.0 and 8.42.0 but rather 2019.01.22 and 2019.03.05.
>
> A drawback of the change is that possible enterprise distributions
> will not package any 2019+ releases until their next major release,
> but I would be willing to accept this in preference of better clarity
> for the user.
>
> If there is no hard objection, I'll change the version scheme with 2019.01.22.
>
> Any concerns please let me know.
>
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
On Sat, 15 Dec 2018, Adam Chalkley wrote:

> FWIW, I think that semantic versioning could be used here, provided that you are willing to progress past 8.x, which this proposal clearly indicates you are willing to do.
>
> I think many users have learned (or are learning) that the first number indicates the potential for major behaviorial changes, so moving past 8.x will be the first indicator that whatever they are using is behind the latest upstream release.

The thing is that every release could be 'major behaviorial changes' if you need
the changes in it, and every release could not be a major change if you don't
use the changes in it. So there is no clear reason to change the major number.

Continuous incrimental development and 'semantic versioning' don't go together
well. This is why so many projects are moving away from it to either sequential
numbers or date based versioning.

David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
Hello Rainer, all,

This scheme does seem most sound for multiple reasons. It retains a kind
of 'major version numbering backward compatibility' for user expectations
and encodes the date as well.

Another way to make it less "wordy", apart from changing YYYY to YY, could
be to drop the DD as well considering (normally) you never release twice in
the same month. Also, continuing to add a ".0" suffix would satisfy the
(legacy) expectation of "x.y.z" kind of version numbers too. If you really
end up making some critical release in the same month as the previous one,
the suffix becomes ".1".

Just a suggestion.

Regards,
Satyam


On Sat 15 Dec, 2018, 10:14 PM Rainer Gerhards <rgerhards@hq.adiscon.com
wrote:

> El sáb., 15 dic. 2018 a las 17:05, Michael Biebl via rsyslog
> (<rsyslog@lists.adiscon.com>) escribió:
> >
> > Am Sa., 15. Dez. 2018 um 15:02 Uhr schrieb Michael Biebl <
> mbiebl@gmail.com>:
> > >
> > > Am Sa., 15. Dez. 2018 um 13:20 Uhr schrieb Rainer Gerhards
> > > <rgerhards@hq.adiscon.com>:
> > > > Any concerns please let me know.
> > >
> > > Maybe interesting to you
> https://joeyh.name/blog/entry/version_numbers/
> > >
> > > This would translate to 8.YYYYMMDD in your case.
> > >
> > > Has the additional benefit, that should you decide to re-architect
> > > rsyslog in a significant way, you can use
> > > 9.YYYYMMDD
> > >
> > > If there is such a potential significant change in the future, there
> > > is some value to it, if a user can quickly see this.
> >
> > One other benefit of keeping the 8. prefix would be, that should you
> > ever decide to change the versioning scheme again, you haven't burned
> > all version numbers up to 2018.
>
> That's indeed a very good argument. To avoid the long version string
> we could also go 2-digit years and bump the "major" version on next
> century change ;-)
>
> Thx for the feedback so far!
> Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: rsyslog version numbering change [ In reply to ]
Thx again for all the good feedback. going 4-digits makes indeed a lot
of sense. I have played a bit with the actual code and think that we
can actually combine both methods when displaying versions. Sample
from rsyslogd -v

rsyslogd 8.1901.0.master (aka 2019.01) compiled with:
PLATFORM: x86_64-pc-linux-gnu
...

IMHO that would make it obvious to a casual user what "1901" actually is.

As always, feedback is welcome.

Rainer
El dom., 16 dic. 2018 a las 1:44, Satyam Sharma via rsyslog
(<rsyslog@lists.adiscon.com>) escribió:
>
> Hello Rainer, all,
>
> This scheme does seem most sound for multiple reasons. It retains a kind
> of 'major version numbering backward compatibility' for user expectations
> and encodes the date as well.
>
> Another way to make it less "wordy", apart from changing YYYY to YY, could
> be to drop the DD as well considering (normally) you never release twice in
> the same month. Also, continuing to add a ".0" suffix would satisfy the
> (legacy) expectation of "x.y.z" kind of version numbers too. If you really
> end up making some critical release in the same month as the previous one,
> the suffix becomes ".1".
>
> Just a suggestion.
>
> Regards,
> Satyam
>
>
> On Sat 15 Dec, 2018, 10:14 PM Rainer Gerhards <rgerhards@hq.adiscon.com
> wrote:
>
> > El sáb., 15 dic. 2018 a las 17:05, Michael Biebl via rsyslog
> > (<rsyslog@lists.adiscon.com>) escribió:
> > >
> > > Am Sa., 15. Dez. 2018 um 15:02 Uhr schrieb Michael Biebl <
> > mbiebl@gmail.com>:
> > > >
> > > > Am Sa., 15. Dez. 2018 um 13:20 Uhr schrieb Rainer Gerhards
> > > > <rgerhards@hq.adiscon.com>:
> > > > > Any concerns please let me know.
> > > >
> > > > Maybe interesting to you
> > https://joeyh.name/blog/entry/version_numbers/
> > > >
> > > > This would translate to 8.YYYYMMDD in your case.
> > > >
> > > > Has the additional benefit, that should you decide to re-architect
> > > > rsyslog in a significant way, you can use
> > > > 9.YYYYMMDD
> > > >
> > > > If there is such a potential significant change in the future, there
> > > > is some value to it, if a user can quickly see this.
> > >
> > > One other benefit of keeping the 8. prefix would be, that should you
> > > ever decide to change the versioning scheme again, you haven't burned
> > > all version numbers up to 2018.
> >
> > That's indeed a very good argument. To avoid the long version string
> > we could also go 2-digit years and bump the "major" version on next
> > century change ;-)
> >
> > Thx for the feedback so far!
> > Rainer
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> > What's up with rsyslog? Follow https://twitter.com/rgerhards
> > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> > DON'T LIKE THAT.
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.