My other mail crossed with these messages, just so that you know. 2014-10-30 15:08 GMT+01:00 Thomas D. <[email protected]>:
> Hi, > > 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? > > Depends on what "important" means. There are many requests in the bug tracker (many for new interfaces, many for logstashish simplicity, unfinished external input plugin interface, rewrite of queue system, replacement of json-c in variable handling come up my mind without any further thinking) and many things make a lot of sense. Part of that is refactoring, but would have very clear benefits (like getting rid of libestr). I'd assume its 1 to 3 years of work for me at the rate that I can currently handle. 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 [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. > Well in theory I agree. In practice, we have tried hard during the last month to make it *easier* for folks to contribute. Wouldn't that requirement be right the contrary and block contributions? Remember that it is a very rare occasion that I receive a bit of doc with a contribution and demanding a *decent* testbench test (no matter which system is used for that) would definitely raise the bar much higher. Assuming that not everyone know how to write for the test systems that's used by rsyslog, it's probably a total show stopper. > 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? > Counter-question: what does people stop from writing doc? I've even split off the rsyslog-doc project early this year and James made it much more accessible and easy to use by supporting RST ... yet almost nobody is contributing. Granted, I can do all the doc work myself, and I am already doing this as good as I can, but I have also said numerous times that *I am simply not good at writing doc*, so the situation will not improve as long as nobody seriously joins that effort. > > 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? > > When I began with open source, the spirit was "anyone helps with what he can do best". It worked pretty decent years ago. I developed, which I am good add, users contributed by trying out the -devel branches and contributed bug reports and testing help. Nowadays, it looks like I need to be the developer-tester-techwriter guy and everybody expects free software to be perfect without contributing back - at least it looks so. Maybe that's the price we have to pay from all these well-funded projects. Unfortunately, we *are* *not* well funded, so we cannot hire test engineers and tech writers. If I get bug reports for important features, I usually try to fix them quickly. Doesn't work always, but works. I also try to keep things running that I do not know very well, or do not know who is actually using it. The commit you mention is a good sample. IMHO it is better to keep the module, as some folks may be using it, and they just have not yet moved to v8 (very likely - I just worked on a thankfully paid support call on v3.22!). If I craft that untested fix right now, I have at least a vague memory of what needed to be changed. If this happens in two years from now, I would have to start right from the beginning. But we can of course remove all that modules that are not mainstream if that's the overall consensus. I think it is good to have them in the source tree, at a minimum they serve as examples and copy-templates for folks who want to do something similar. All in all: I really like the feedback and hope I don't come over harsh. It's not the intention. I just want to state the problem *from my perspective* (which I think is not obvious), so that this can be put into the picture. More comments and suggestions are highly welcome (Radu? David?). Thanks for the discussion! Rainer > 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.
