Thanks for the schedule information! I'll try to have the new rsyslog plugins ready for the 2014-12-02 release. The output plugin should be "finished" this week and then I'll be starting in on the new input.
Brian On Sat, Nov 1, 2014 at 6:20 AM, Rainer Gerhards <[email protected]> wrote: > Just FYI folks. I am now switching to a 6w cycle. Expect blog posts to come > up. The next release will be 8.6.0 stable, based on 8.5.0. I've also done > a little bit of calendar lookup. I don't like to start a new release cycle > method with an exception, and I don't do releases before the xmas holiday > period. As such, we will have the following upcoming release dates: > > 8.6.0: 2014-12-02 > 8.6.1: 2015-01-13 > > Just so that you know. > > Adiscon will probably post non-project, adiscon-specific interim releases > to the Adiscon repositories. This is because we need to deliver > fixes&enhancements to support customers in package form (for the paying > customers, it's not an option to build from source). Just think of the > Adiscon packages in the same way now like you do about RH, Debian or Ubuntu > packages. The Adiscon repositories will remain open to everyone. > > I also continue to setup more testbench machines. > > Rainer > > 2014-10-31 12:56 GMT+01:00 singh.janmejay <[email protected]>: > > > +1 for 6w > > > > -- > > Regards, > > Janmejay > > > > PS: Please blame the typos in this mail on my phone's uncivilized soft > > keyboard sporting it's not-so-smart-assist technology. > > > > On Oct 31, 2014 4:07 PM, "Rainer Gerhards" <[email protected]> > > wrote: > > > > > 2014-10-31 11:01 GMT+01:00 David Lang <[email protected]>: > > > > > > > On Fri, 31 Oct 2014, Rainer Gerhards wrote: > > > > > > > > 2014-10-31 0:38 GMT+01:00 David Lang <[email protected]>: > > > >> > > > >> On Thu, 30 Oct 2014, Rainer Gerhards wrote: > > > >>> > > > >>> > > > >>> > > > >>>>> +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. > > > >>>> > > > >>>> > > > >>> I'm actually thinking of the kernel model > > > >>> > > > >>> every X months release 88.7, 88.8, 88.9, etc. If there are bugfixes > > > that > > > >>> need to go out between the X month releases, they become 88.7.1 > > 88.7.2 > > > >>> etc. > > > >>> 3-6 months seems to work fairly well for individual projects. In > > > between > > > >>> people can just compile from the master. I don't think we have > enough > > > >>> testing participation to go the -rcX route. > > > >>> > > > >>> If there is a major (risky) change, it would justify an 89 release, > > but > > > >>> that would end up being something like a re-write of the queue > model > > or > > > >>> other very intrusive (and therefor risky) change, not the ongoing > > > >>> features, > > > >>> modules, performance optimizations. > > > >>> > > > >>> > > > >>> mmhh... isn't that -except for the timing- what we do with the > > current > > > >> -devel/-stable just in other terms? I agree that terms are important > > but > > > >> should we than name the master branch releases as stable and the > > monthly > > > >> as > > > >> "old stable". Also, I have the impression that with the kernel > almost > > > >> everyone uses the bi-annually releases (in our words the -stable) > and > > > not > > > >> the master. > > > >> > > > >> If I am not wrong, that model would probably result in the same > > problem, > > > >> that is I develop new things in master branch, but everyone begins > to > > > >> "test" them when it is rolled into the bi-annually releases. > > > >> > > > > > > > > The releases don't need to be bi-annual, there are advantages to > > shorter > > > > cycles. > > > > > > > > People do need some stability in what's shipped, so they really > aren't > > > > going to be running things from git. So the question is, "how quickly > > can > > > > you release things without annoying people too much?" > > > > > > > > for the kernel, they are making new releases about every 2.5-3 > months. > > > > Firefox is making releases about every 6 weeks. I don't remember what > > > > Chrome's cycle is like, but it's also rapid. > > > > > > > > > > > So how about every 6 weeks for rsyslog? On that cycle, bug reports > would > > > still hit me with a relatively fresh idea of what I changed. > > > > > > Rainer > > > > > > > > > > People are going to start off being afraid of new releases, but they > > seem > > > > to accept them if they don't have frequent regressions. They also > seem > > > far > > > > more afraid of changing major versions than minor versions (and even > > > there, > > > > firefox and chrome are getting people to accept that) > > > > > > > > > > > > Today we have the master tree, -devel releases, -stable releases, and > > > > bugfix releases. > > > > > > > > I'm saying that we would have the master tree, -stable releases, and > > > > occasional bugfix releases (the bugfixes would only fix regressions > > that > > > > were missed) > > > > > > > > > > > > David Lang > > > > _______________________________________________ > > > > 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. > > > > > _______________________________________________ > > 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. > _______________________________________________ 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.
