Date: Mon, 2 Sep 2019 08:12:08 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Enji Cooper <yaneurabeya@gmail.com>, Hans Petter Selasky <hps@selasky.org>, Ed Maste <emaste@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, fcp@freebsd.org, Li-Wen Hsu <lwhsu@freebsd.org> Subject: Re: FCP 20190401-ci_policy: CI policy Message-ID: <201909021512.x82FC8ZD009673@gndrsh.dnsmgr.net> In-Reply-To: <201909011948.x81JmbS3004574@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <8350379A-30F8-4BBD-B9AE-A3A176CAE966@gmail.com>, Enji Cooper > writes > : > > > > > > > On Sep 1, 2019, at 10:42 AM, Hans Petter Selasky <hps@selasky.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201909021512.x82FC8ZD009673>