Date: Tue, 3 Sep 2019 14:16:30 -0700 From: Enji Cooper <yaneurabeya@gmail.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: Cy Schubert <Cy.Schubert@cschubert.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: <911BCF8B-CF37-48A5-B3FE-B5959575A996@gmail.com> In-Reply-To: <201909021512.x82FC8ZD009673@gndrsh.dnsmgr.net>
index | next in thread | previous in thread | raw e-mail
On Sep 2, 2019, at 08:12, Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> wrote: >> 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. I agree with you in spirit. It just makes it easier if it’s implemented in a structured process, so I don’t have to look up the committer’s guide to figure out what the rules are, then apply them. -Enjihelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?911BCF8B-CF37-48A5-B3FE-B5959575A996>