Thinktank: CI's, compiler lists, and project automation

[Nick Sabalausky (Abscissa)]

(I'm posting this here instead of D.learn because it isn't really a "How 
to do XYZ in D?", but rather to invite discussion on high-level 
solutions to a problem.)

Here's a common problem:

1. A project (ex, some library) uses travis-ci (and/or other) to ensure 
compatibility with a range of compiler versions. The travis 
configuration file includes a manually-curated list of compiler versions.

2. CI tests are triggered by new commits/merges/PRs in the project.

3. New compiler versions are released.

4. Compiler updates may or may not trigger new tests with the new 
compiler, depending on the project.

5. Project maintainer must manually update the list of compilers. (And 
this isn't one task, but rather O(n), where n=number of projects the 
given person is maintaining).

The challenge: What is the best way to automate this? (ie, #4 and #5)

We do already have certain approaches to at least certain facets of the 
problem (ex: some third party libs are included in DMD's CI testing), 
but there are still limitations and downsides (ex: D tester has limited 
resources, and it doesn't address manually updating the travis config's 
list of compilers or notifying authors their project's compiler list 
needs updated.)

Another sample point of discussion: One possible approach is to have a 
bot generate PRs to update project's compiler lists. But that leads to 
other questions: How/when is the bot triggered? On what machine does it 
run? Is there an existing jumping-off point for creating such a bot? How 
does it approach the task of modifying `.travis.yml` (how smart/dumb 
does it need to be)? Any security concerns to be mindful of? Etc.