Monday, January 12, 2015

rsyslog branches and git history

There was a lengthy mailing list discussion in November and December  of 2014 of whether or not to avoid git merge entries. There was also an intermingled discussion on QA and CI. The idea was to trim the git history and make sure tests are run a quickly as possible. As a result of that discussion, I added more automated testbench runs, which also required a new branch master-candidate, which is used as a staging area to run the test, and from which changes are (manually) migrated to master when all testbench runs are OK. In order to avoid merge entries in git log, I made master-candidate the default github branch and also asked contributors to file PRs against that branch.

I've now tried all of this for a couple of weeks. That approach works, but it creates a lot of overhead and quite some confusion for a lot of folks. Some users have voiced they don't really care if there is a merge entry. Fewer have voiced they don't like them. Michael Biebl has pointed out that it is easy to make them disappear from "git log", via the --no-merges command line switch.

After careful consideration and some frustration, I conclude that avoiding merge entries is unnecessary overhead for me. Being the 90%+ contributor for this project, I conclude that avoiding merge entries is unnecessary overhead for the project. As such, I will no longer try to avoid them at all costs. I will, however, try to keep the git history as neat as possible .. but not any more.

As such, I'll reset the default branch on github to "master" and will accept pull requests to master. Internally, everything still needs to go through master-candidate, as this is how the new testbench setup requires. If someone doesn't like this approach to the testbench, I am open to changes, BUT I than ask that someone to actually contribute running code to make that change happen. Good advise only is good, but doesn't help getting things done at this stage. We already know the advise, we just have nobody who has time to implement it!
I would like to thank all users for their comments. I think they have considerable helped move forward. Sorry that I could not accept all suggestions. I guess it's like always in life: not everybody can be fully happy. But I hope we have achieved a sufficient level of overall happiness :-)

No comments:

The clang thread sanitizer

Finding threading bugs is hard. Clang thread sanitizer makes it easier. The thread sanitizer instruments the to-be-tested code and emits u...