FCP 20190401-ci_policy: CI policy

[Ian Lepore]

On Thu, 2019-08-29 at 14:40 +0300, Konstantin Belousov wrote:
> On Wed, Aug 28, 2019 at 12:29:58PM +0800, Li-Wen Hsu wrote:
> > It seems I was doing wrong that just changed the content of this FCP
> > to "feedback", but did not send to the right mailing lists.
> > 
> > So I would like to make an announcement that the FCP
> > 20190401-ci_policy "CI policy":
> > 
> > https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md
> > 
> > is officially in "feedback" state to hopefully receive more comments
> > and suggestions, then we can move on for the next FCP state.
> 
> What problem does the document tries to solve ?  Or rather, do we really
> have the problem that it claims to solve ?
> 
> From my experience, normal peer pressure is enough to get things fixed
> quickly when it is possible to fix them quickly. If there is something
> more non-trivial, esp. in the tests and not the build, I am sure that
> a rule allowing anybody to do blind revert is much more harmful than
> having a test broken.
> 
> More, I know that tests are of very low quality, which means that
> brokeness of the tests is not an indicator of anything until root cause
> is identified.
> 
> Can we rely on the common sense of developers until there is indeed the
> visible problem ?
> 

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.  (And I don't think breaking a test counts as
breaking the build.)

[*] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.html

-- Ian