See also issue843.

We reviewed the config file and decided on where to store it during the last
sprint. We decided to postpone the discussion about the test to run. I created
issue888 for this and am closing this one.

I don't have any specific suggestions. I don't think these tests will ever do a
great job at detecting performance regressions. For unexpected whole-planner
changes that show up in the number of expansions etc., they are already useful.

While working on issue876 we found that we are currently ignoring some
attributes like total_time in the nightly/weekly regression tests because only
small instances are tested and their values are below the reporting threshold.

We should add more instances to the mix. What do you think would be a good
benchmark set?

There is no real technical obstacle to committing the master.cfg either way. If
it's not up to date in the repository and if that is causing problems, it should
be committed. I suggest you discuss the details between yourselves. The only
thing we need to be aware of is not to commit anything that includes passwords.

I think wherever the master.cg lives, it has to be up-to-date. If that's easier 
to accomplish in the infrastructure repo, then we should move it there. The 
current situation is very confusing (and just cost me twenty minutes while trying 
to use outdated commands from an outdated master.cfg on the Windows buildbot 
:-)).

I remember that having the buildmaster file in the Fast Downward repository has
led to annoying bootstrapping issues in the past that required quite a bit of
manual copying back and forth. This would be an argument in favour of moving it
to the infrastructure repository.

By this I don't mean I recommend that change; there may be good arguments against.

The docker buildbot setup is running but was not reviewed yet. In issue866 we
noticed that full builds are not always run and linker warnings can disappear in
a second build if the build succeeds the first time.

We also should consider the place where the master.cfg file should live.
Currently, we have an outdated one in the Fast Downward repository and the one
that is used in the infrastructure repository. In the docker setup there is
already a placeholder to fetch the config from the Fast Downward repository in
case we want to keep it there but we could also move it to the infrastructure
repository permanently.