[rsyslog] Feedback Request: do we still need -devel versions?
whissi at whissi.de
Thu Oct 30 15:08:22 CET 2014
On 2014-10-30 14:03, Radu Gheorghe wrote:
> -1 for time-based releases, as I think they're more appropriate for [much]
> bigger projects. I would release when it's worth releasing (i.e. it's ready
> when it's ready)
To clarify this:
When I said +1 for a time-based release I am not saying we must release
a new version every x weeks. So if nothing is ready, well.. we will skip
this date and maybe release a version on the next scheduled date.
The important thing about time-based releases are that releases are
scheduled. If you reported a problem and it was fixed you can pull the
patch from master any time or wait for the next version. Waiting for the
next version isn't a problem anymore because thanks to the time-based
release cycle you know when a version with this fix will be released.
And for developers, if you did not make it into the release - don't
worry. The next release is already scheduled. No need to feel bad or
commit bad code just to get it into the release...
> Regarding code quality: I have a QA background so I tend to put a[n overly]
> big price on testing and documentation. But I still wouldn't stop moving
> forward with the project for the sake of quality - Rainer adds juicy stuff
> with every release and, looking back, I'm always thinking what a nice
> progress this project has made.
> However, I think there's increasing debt in terms of tests and docs as new
> features are added. As rsyslog gets more complex, it looks harder to keep
> it stable.
> So I would go with something in the middle: when a new feature is done,
> let's add docs and some basic tests to the testbench to it. If we want to
> make exceptions, let's add a github issue with a few useful pointers so we
> can "catch up" later.
Are there any important missing features in the pipeline?
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.
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  (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
4) If a new feature or a change will break something, we would
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?
More information about the rsyslog