From owner-freebsd-fcp@freebsd.org Mon Sep 2 15:12:20 2019 Return-Path: Delivered-To: freebsd-fcp@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CE13CE0A55 for ; Mon, 2 Sep 2019 15:12:20 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46MYTw3mDFz3NrF for ; Mon, 2 Sep 2019 15:12:20 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: by mailman.nyi.freebsd.org (Postfix) id 810D2E0A4F; Mon, 2 Sep 2019 15:12:20 +0000 (UTC) Delivered-To: fcp@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 80BE5E0A4E; Mon, 2 Sep 2019 15:12:20 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46MYTv1nHyz3Nr9; Mon, 2 Sep 2019 15:12:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x82FC9cD009674; Mon, 2 Sep 2019 08:12:09 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x82FC8ZD009673; Mon, 2 Sep 2019 08:12:08 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201909021512.x82FC8ZD009673@gndrsh.dnsmgr.net> Subject: Re: FCP 20190401-ci_policy: CI policy In-Reply-To: <201909011948.x81JmbS3004574@slippy.cwsent.com> To: Cy Schubert Date: Mon, 2 Sep 2019 08:12:08 -0700 (PDT) CC: Enji Cooper , Hans Petter Selasky , Ed Maste , FreeBSD Hackers , fcp@freebsd.org, Li-Wen Hsu X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 46MYTv1nHyz3Nr9 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.62 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.38)[0.377,0]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.05), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.36)[0.364,0]; NEURAL_HAM_LONG(-0.07)[-0.067,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fcp@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FreeBSD Community Proposals List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 15:12:20 -0000 > In message <8350379A-30F8-4BBD-B9AE-A3A176CAE966@gmail.com>, Enji Cooper > writes > : > > > > > > > On Sep 1, 2019, at 10:42 AM, Hans Petter Selasky wrote: > > > > > > Hi, > > > > > > If the fallouts could be better organized through some simple guidelines, t > > hat would be more accepted I think: > > > > > > 1) Don't commit stuff before going off work. Even though a change looks inn > > ocent, it might break something and you'll need to fix it. > > > > > > 2) Organize big changes going into the kernel, to ease debugging and gettin > > g things back on track again. > > > > > > 3) If your patch is risky, commit it on a Monday. Don't wait until Friday. > > > > > > Failure to follow the rules may have consequences like other senior develop > > ers kicking in and doing temporary reverts until issues are resolved. > > > > Agreed. There???s a reason why at my most former job (FB) we generally knew b > > etter than to commit code on a Friday. It would cause the weekend oncalls a l > > ot of grief. > > > > Let???s put it this way: think of it like being oncall for code. If you don?? > > ?t have someone else to work with who can manage it, would you like to be pag > > ed if something went south with your code committed on a Friday? > > This is a good idea. Pinging someone to provide backup support is a good > idea. phk@ has asked me in this regard once giving me authority to back out > his commit should it cause any grief. It didn't break anything but he made > contingency plans just in case. All of these can be codified into "operational suggestions" and added to the committers guide, and does not necessarily need to be rules, policy or procedure, that should help move it forward past the high bar of trying to get changes like this codified some place that everyone can read. -- Rod Grimes rgrimes@freebsd.org