2014-11-11 3:03 GMT+01:00 David Lang <[email protected]>: > On Mon, 10 Nov 2014, Thomas D. wrote: > > Hi, >> >> On 2014-11-08 00:19, David Lang wrote: >> >>> Then when the feature is believed to be complete, it gets merged into a >>> 'pending' tree. This tree exists for the sole purpose of having the >>> testbench >>> run against it daily. This tree is not stable, it's recreated for each >>> day's >>> test run by copying the master and then merging in all the pending >>> features that >>> are beleived to be ready to be tested. >>> >> >> Mh... that's sounds like you don't always want to do QA. Then I disagree >> with you. >> >> QA should always be there. You shouldn't think about QA at all, because >> if we have CI, everything will happen automatically in the background. >> You don't need to care but if there is a QA problem, you will be notified. >> >> >> As a note on CI testing, no large entitiy does a full test run against >>> each >>> commit individually, this just doesn't scale. At some point the tests >>> just take >>> too long to run. So they fall back to doing the tests at a larer >>> granularity, >>> possibly with unit tests being run on each change (if you can define >>> unit tests >>> in a way that lets you decide easily what tests are relevant to the code >>> that >>> was changed) >>> >> >> Unit tests should *always* run. >> >> Some functional tests maybe skipped and only run when you are preparing >> a release. >> >> But the discussion is very theoretical at the moment. Github's Travis is >> very powerful. Let's wait until we really know how much time rsyslog's >> test suite would actual take. >> > > it all depends on how long the tests take to run. If it takes a couple > hours to run the tests, you aren't going to want to do them for every > commit. Doing them frequently is important, but it's not so important that > you need to throttle development to the speed that the tests can run. > > >> As for the history being dominated by merges, this is the result of >>> maintaining >>> so many different versions. As John noted when he did the documenation >>> tree, >>> merging changes into the oldest supported version and then merging that >>> into the >>> newer versions lets git do a LOT of work for you in how it remembers what >>> changes have been made and integrating the new changes into it. >>> >> >> Merging down instead of merging up would also help: >> > > I don't think so. Git already knows about the changes in the one > direction, so layering some additional changes on isn't that hard, but > moving the other way requires that git figure out where the change came > from in order to 'do the right thing', and that's a much harder thing to do. >
... especially as (to the best of my knowledge) git does not do that. So on the way down, you need to manually do the merging. 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.
