On Thu, 30 Oct 2014, Thomas D. wrote:
Date: Thu, 30 Oct 2014 15:08:22 +0100
Are there any important missing features in the pipeline?
important to who? There is a years-long backlog of little features that will be
incredibly useful to people, plus ongoing work on the feature of performance
that never ends.
When Debian Jessie is out, things are done for a moment. I am not
suggesting to stop further development at all, but we should focus for
3-6 months on a test suite (and remember, the test suite will only
uncover bugs, and I am expecting to find a lot of bugs).
There are dozen of modules. Most of them were created to solve one
special problem. But many of them are lacking of the modern syntax and
or documentation. Often they don't even work.
The issue is the split between core and contributed code. The core code has
pretty good test coverage and fair documentation. The Contributed modules are in
much worse shape. It doesn't help that there is no good deliniation between the
two.
David Lang
I am not happy with shipping code you don't know. And this year has
shown that sometimes it is better to remove code you don't know... ask
the OpenSSL team ;)
And to be honest, I am little bit shocked that if you are having a QA
background that you are suggesting an exception model. Don't get me
wrong, but isn't that the point where every problem starts?
For example, see commit b342337f [1] (please Rainer, don't get me wrong
here, too!). The mmcount module was broken for about 1 year and nobody
noticed. And even now, we don't know if it is working.
If we would stop for a moment, create a test suite and also a policy
like "Only merge working code; only add new things when they are
documented; only add new things when we have a working test" we would
solve this problem.
1) We would know what's working and what isn't working.
2) Because the tests will verify our documentation/specs we would know
if something doesn't work as expected.
3) Because we have working tests we should be able to reproduce most
problems (currently there's often the problem that a special environment
is needed).
4) If a new feature or a change will break something, we would
immediately notice.
What's the benefit of having a feature nobody knows or nobody can use,
because we don't have a documentation?
What's the benefit of having a new feature very fast when you don't know
if it is still working in the next version because you cannot test?
See also:
=========
[1]
https://github.com/rsyslog/rsyslog/commit/b342337f70772417fc9dcec0014baa02101cfd3b
-Thomas
_______________________________________________
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.
