FCP 20190401-ci_policy: CI policy

[Ed Maste]

>> This sounds more like a problem with the tooling than an argument
>> against reverting though.
>
> We live in a subversion universe for the moment, so you have to view it through that lens.

Fair enough, right now the policy needs to accommodate the reality of
the tools we're using today.

Perhaps it's a failure of imagination on my part but I have trouble
seeing how a revert would lead to losing work - could you give an
example?

> Sometimes yes, sometimes no. Even with git svn, there is a cost associated with it.  The level of effort is not zero. Especially when one pushes several interrelated changes at once. If the first of these caused an issue on gcc, say, often the cost is too high to revert the whole chain. It's a lot easier to put in a fix and move on.

The level of effort imposed on other users while the tree is broken is
not zero, either. Certainly if it's possible to commit a fix and move
forward that's the approach favoured by community norms.

> It's a fair example for why a simpleminded approach will create more friction than the current system. And there is a need for caution in expanding the logic beyond all but the most recent changes...

The point of the FCP is to facilitate the revert while the change is
(among the) most recent, precisely so that additional changes don't
build on it.