Hi, 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 [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.
