Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Aug 2019 08:42:25 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        Konstantin Belousov <kostikbel@gmail.com>, Li-Wen Hsu <lwhsu@freebsd.org>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>, fcp@freebsd.org
Subject:   Re: FCP 20190401-ci_policy: CI policy
Message-ID:  <28934eb780342605090bf365ac3a2e0d522256f5.camel@freebsd.org>
In-Reply-To: <20190829114057.GZ71821@kib.kiev.ua>
References:  <CAKBkRUwKKPKwRvUs00ja0%2BG9vCBB1pKhv6zBS-F-hb=pqMzSxQ@mail.gmail.com> <20190829114057.GZ71821@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28934eb780342605090bf365ac3a2e0d522256f5.camel>