Hi, I agree with everything David and Michael already said. But I wouldn't add a time-limit for pushing a new release: For example if there's a broken release tarball or a really bad bug which broke major functionality but which only affects some architectures we maybe won't notice that within the first 24-72 hours (remember the nasty x86 bug in the ~8.8 release?).
I would always push a new release if the release tarball isn't usable or a major functionality is somehow unusable. Now all we have to do is to define what we call a major functionality and if we all consider a broken test suite critical or not ;) Some additional comments: Like Rainer quoted in my mail from October 2014: If you (rsyslog team) are not ready to publish a new feature on a scheduled date, that's fine. Do _not_ publish this code because just we hit the release date. One important thing about this release cycle is that it should _remove pressure_ from all: If we miss a date, don't worry, we all already know when the next opportunity will appear. So you _did everything right_ by pulling these changes for the v8.14 release when they weren't yet ready for _some_ reasons (and that will include "feelings": If your stomach worries about the changes, do _not_ publish! Your are the one who knows best about rsyslog. We all trust you and nobody will blame you for hiding back a new feature (remember that people can always pull from git if they cannot wait)). Also don't worry because you are doing a big release before holiday: You should only care about the code/product quality. If the new release meets the quality the rsyslog team wants to ship, ship it. If it don't meet the quality or you just don't know, wait. And if you ship there are always the user/distro maintainers who will decide at the end of the day if they will adopt the new release or wait for _their_ reasons. ;) Final suggestions: 1) The master branch should always be ready to release. So when you merge something into the master we all know that will be part of the next scheduled release. 2) Because of #1, never ever disable tests in master for $reasons. There is _nothing_ which justify something like that (=so don't merge something with disabled tests). If there's a test failure for some reasons that's an indicator that the code doesn't meet the project's quality requirements. Don't even start thinking "Well, that's just a small test... and I also know that's a bad test I wanted to replace/get rid of years ago... do I really have to care?" -- Define quality. Make sure that features are tested. Don't accept contributions without tests (while it is nice to have contributions, once you have integrated the code the rsyslog project will become responsible for maintaining that code. Because of that only accept things if they meet your requirements). You can always play around in feature branches. But keep the master in a well known reliable state. -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.
