FCP 20190401-ci_policy: CI policy

[Konstantin Belousov]

On Thu, Aug 29, 2019 at 07:44:59PM -0400, Ed Maste wrote:
> >> 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?
If you have a committed change that is the precursor for later series,
and this series is not yet committed.  Then rebase or merge of the
master with the base change reverted causes much trouble.

> 
> > 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.

Also, I have to admit publically, that my changes were blamed by CI so
many times, when they had nothing to do with the breakage.  I forwarded
such mails to ci@ regularly, then stopped doing that.

Also, I believe that imposing requirements on committers to not offend CI
is not fair if committers cannot _easily_ verify that the change does not.
Give us a way to e.g. mail pgp-signed message to ci-check@ and get the
reply 'ok/fail' in reasonable time, or a button on phab to get the same
response.  Even if I bother to recreate CI env locally (I do not), races
are different on the CI machines.