2014-10-30 13:31 GMT+01:00 Thomas D. <[email protected]>: > Hi, > > +1 for an always working "master" branch. > > Do your work in feature branches. Only merge when you think the changes > are ready. Don't merge when you think "I am ready, but this needs testing". > > yeah, but isn't that essentially the same problem? Except for extremely small changes, I work with feature branches and I usually try to find somebody who does external verification before I merge. But that doesn't work in all cases. So in essence, I need to merge at some point, based solely on my testing.
> Regarding the testing problem in general: I would stop adding new > features for a while. Spend more time in improving code quality. > That's what I am trying to do the past couple of weeks. Nevertheless, feature requests always come up. And going to a testing-and-fixing only mode would probably mean no releases for a long period of time. Plus, for many plugins I am far from being an expert for that subsystem. So it requires considerable amounts of time just to setup test labs and even more causes my problems find out how to automate things. > Try to find/create a working test suite. There will always be the > problem that nobody will test your stuff. So you need a way to write > tests. Yes, creating a test suite will take some time. But in the end it > will improve the software quality and boost your development. > rsyslog has a test suite for many years now, and I am continuously expanding it. But it unfortunately covers only a subset of the code pathes. Some of this is fixable, but e.g. config option interaction grows exponentially, so you can never write (or run) sufficient tests for that. Still, it would be very well to add a couple of hundred test cases, but than the problem given above kicks in. Right now, I usually try to add a test for any problem that was seen in practice. The testbench is invoked via "make check". It is run automatically every day around noon CET and I receive notifications of these results. Remember that you can use CI for free with GitHub. Every pull request > could be automatically tested for you... > This sounds good, but it also means that I need to learn a new system and convert the existing testbench. Another thing that heavily hits the time budget. > > > +1 for a time-based release approach. > I am not sure if David and you talked about the same thing. If I understood David correctly (please correct me if I am wrong), he says that we release versions (88 to avoid confusion with existing versions), e.g. 88.6.1, 88.6.2, 88.6.3, 88.6.x whenever they are ready. However, every 6 month we would begin a new series, e.g. 88.7.1. From then on, only 88.7 is updated. For real "we release each ... Tuesday in the first week of the month" time-based approaches I have started a little experiment. Actually, usually had released a 8.4.3 version when I saw and fixed that big bug in imfile's inotify code that makes rsyslog abort when multiple files are defined. That would have been around two weeks ago. This time, I did not release and tried to wait until Nov, 4th. As it looks, this hold of release seems not to have caused much harm (only one or two duplicate bug reports) and on the pro side the now upcoming 8.4.3 is a "fatter" release in that it contains more fixes (in other words: would probably have been two releases with the regular paradigm). While this may be a too-quick conclusion, it points to the direction that it is possible to do releases just once a month. > > PS: Debian Jessie will freeze at 23:59 UTC on the 5th of November 2014. > Just a reminder if you want to see some of the recent changes in Jessie... > > Yeah, probably 8.4.3 will be too late for this. But I think it simply is impossible to run on a fixed schedule AND take care about the many, many distros and their release cycle. 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.
