Date: Sun, 01 Sep 2019 12:48:37 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Enji Cooper <yaneurabeya@gmail.com> Cc: Hans Petter Selasky <hps@selasky.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Ed Maste <emaste@freebsd.org>, Li-Wen Hsu <lwhsu@freebsd.org>, Warner Losh <imp@bsdimp.com>, fcp@freebsd.org Subject: Re: FCP 20190401-ci_policy: CI policy Message-ID: <201909011948.x81JmbS3004574@slippy.cwsent.com> In-Reply-To: <8350379A-30F8-4BBD-B9AE-A3A176CAE966@gmail.com> References: <CAKBkRUwKKPKwRvUs00ja0%2BG9vCBB1pKhv6zBS-F-hb=pqMzSxQ@mail.gmail.com> <20190829114057.GZ71821@kib.kiev.ua> <CAPyFy2BNrFfZ1PHaLesW%2Bu7YmbhC7mtiZ%2BBsYrqYE0J7KdagaA@mail.gmail.com> <20190830065534.GC71821@kib.kiev.ua> <CAPyFy2CXVMEXZx0u9b0p_CVaD_gu8Gyzvud3KwEDciq83a2_8A@mail.gmail.com> <73111.1567263258@kaos.jnpr.net> <CANCZdfqJzpxj7-P7XN7GEsECEA%2BLaUq6yQJ98OQUp_gXX9FF9Q@mail.gmail.com> <CAPyFy2CdddbDZYNod1ze1Z2iMyggSPP5kQV6ePeKSRQntezZEQ@mail.gmail.com> <CANCZdfoWAuSCKqFwWsnXTmznyuazHfy0tAfgZEv1m92MeSHAEg@mail.gmail.com> <44a1a905-9b35-620b-281c-cdbbee538bed@selasky.org> <8350379A-30F8-4BBD-B9AE-A3A176CAE966@gmail.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. > > Cheers, > -Enji -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201909011948.x81JmbS3004574>