FCP 20190401-ci_policy: CI policy

[Rodney W. Grimes]

(unneeded context removed)

> > In either scenario we end up reducing test coverage, which means we?re
> > going to push more bugs towards users.
> >
> > > I totally agree.  This is an overly-bureaucratic solution in search of
> > > a problem.
> > >
> > > If this needs to be addressed at all (and I'm not sure it does), then
> > > another sentence or two in bullet item 10 in section 18.1 [*] of the
> > > committer's guide should be enough.  And even then it needn't be
> > > overly-formal and should just mention that if a commit does break the
> > > build the committer is expected to be responsive to that problem and
> > > the commit might get reverted if they're unresponsive.  I don't think
> > > we need schedules.
> > >
> > I do feel that?s a better argument. We?ve always had a policy of
> > reverting on request (AIUI), so this is more or less trying to be a
> > strong restatement of that, more than a fundamental shift in policy.
> >
> 
> We don't have a policy to revert commit, actually revert commit is
> something bad, it is kind of punishment, I have been there, nobody wants to
> be there. Stop to push this non-sense argument.

Here in lies one of the fundemental problems, this view by some that
a "revert commit is something bad, it is kind of punishment".  That is
not true.  Reverts are GREAT things, they allow the tree to be returned
to a known state, usually quicly.  The original commit is STILL IN SVN,
and a bad revert can guess what.. be reverted!.

IMHO the project as a whole needs to overcome its fear of reverts and
start to use them for the great and powerful things that they are.

This connection of bad and punishment needs to stop, and the sooner
the better.

-- 
Rod Grimes                                                 rgrimes at freebsd.org