FCP 20190401-ci_policy: CI policy

[Ed Maste]

On Thu, 29 Aug 2019 at 17:32, Warner Losh <imp at bsdimp.com> wrote:
>
> In the past, if someone had any follow on work at all in their tree, the
> reversion would be quite disruptive to that work.

This sounds more like a problem with the tooling than an argument
against reverting though.

I agree that in the case where the fix is straightforward it's
sensible, and in line with community norms, to just commit it. But in
the case that a regression was introduced by a committed change,
modern tools facilitate reverting and replaying changes without a lot
of effort.

> things quickly, imho, to hesitate a little on the revert. Especailly when
> the broken thing is the playstation loader on powerpc that can stay broken
> for the hour or six (or even days) it takes me to figure out why it
> broke... Often things away from the beaten path don't get discovered for
> days or weeks or months, and a reversion then can be extremely disruptive
> if there's other changes layered on top of the offending commit....

Note that this isn't at all the issue under discussion in the FCP,
which refers to issues that have already been detected by CI. For
example, a commit which means amd64 panics on boot. Reverting quickly
is a benefit in this sort of case found by CI precisely so that we
don't end up with other changes on top that are difficult to unwind.