I moved the new info to a new page and fixed the typos.

On second thought, I can't find time for this right now, and I can't add an
unbounded number of items to the TODO list, so this will have to do. Two small
things I noticed that I suggest changing:

- The new text on http://www.fast-downward.org/ForDevelopers/CodingConventions
says "We recommend using Ubuntu 16.04 or 18.04 for Fast Downward development
since these versions are also used by the core developers and they allow
installing all dependencies except VAL and Uncrustify 0.61 via the package
manager." but that's not true: other dependencies not installed via the package
manager include CPLEX, py.test and pyflakes.

- The bitbucket-pipelines.yml file (in the comments) says "Setup" (noun) a few
times where it should be "Set up" (verb).

Longer term, it would be nice to have a clearer documentation of supported OS
versions and dependencies, in one place, talking separately about user
dependencies and developer dependencies. But I can't time for this at the moment.

I had a look, but I don't think this fits well under coding conventions. There
was some old related information there already, but I think that should perhaps
have its primary location somewhere else too, perhaps with a link from the
coding conventions page. I'll try to get this started.

I merged the code and added some infos to http://www.fast-downward.org/ForDevelopers/CodingConventions .

I saw no strong objections on the list, so I think you can go ahead with this.
As you do, please add something to the developer documentation that lists our
supported operating systems and operating system versions for developers.

Is a meeting the right thing for this? I would write an email to downward-dev.

OK, I'll add it to the meeting agenda.

OK, but please let's get buy-in from everybody before merging. For example for
me it means that I will no longer be able run the tests on my university
computer, as I'm running Ubuntu 17.04, which does not seem to have the
appropriate version.

If you're right and 16.04 has the package, then that means that there are
exactly two Ubuntu versions right now that people could use: 16.04 and 17.10.
This does seem quite limiting; after all, my version is not even a year old.
(You also mentioned 18.04, but that isn't even released yet.)

I understand your concern. However, obtaining the binaries looks quite simple for 
all major platforms (including MacOS and Windows): 
http://releases.llvm.org/download.html has prebuilt-binaries for clang and clang-
tidy (both are in a single archive for each system).

I am just worried we are increasing the barrier of entry to Fast Downward
development. If we want to say that Fast Downward developers must use Ubuntu
16.04+, that should be communicated clearly and agreed between everyone.

I think it's easy to set up on Ubuntu machines. The two required packages 
clang-5.0 and clang-tidy-5.0 are available in all supported Ubuntu versions 
since 16.04 (xenial, artful and bionic).

Setting this up on the grid and our Windows machine could be more difficult, 
but we have never run any style checks there before, since the style is checked 
by the Linux buildbot anyway.

Well, I think that definitely needs buy-in from everybody. I guess it would help
if we could first figure out how difficult this is to set up. If we can easily
set this up on all buildbots and on the grid, then I suppose it cannot be too
bad on our other machines.

Yes, but I think that's a good thing. Otherwise, tests might pass locally and 
fail remotely. Especially, if we ever specify checks with wildcards like 
"performance-*". Then different versions might use different sets of tests.

Looks good to me in principle, but does it mean that everyone has to install
exactly the same clang-tidy version (5.0)?

The integration worked well, I think. I made a pull request at 
https://bitbucket.org/jendrikseipp/downward/pull-requests/82 .

I selected only three clang-tidy checks to keep the diff small (performance-
for-range-copy, performance-implicit-cast-in-loop and performance-inefficient-
vector-operation). We can add more checks later. I think automatically finding  
suboptimal code like in the patch is a nice feature to have.

See https://clang.llvm.org/extra/clang-tidy/ for info about clang-tidy. Some 
quick tests give the impression that this tool could be useful for us. I'd like 
to see how difficult it is to integrate it into our testing infrastructure.