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>