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.
David Lang
If someone experiences a problem and we would tell him/her he/she should
try to reproduce the problem with master, a patch would land in master
first. In future we have a clean history, which would help doing a
bisect for example.
_______________________________________________
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.
