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> References: <201909021512.x82FC8ZD009673@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 2, 2019, at 08:12, Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> w= rote: >> In message <8350379A-30F8-4BBD-B9AE-A3A176CAE966@gmail.com>, Enji Cooper=20= >> writes >> : >>>=20 >>>=20 >>>> On Sep 1, 2019, at 10:42 AM, Hans Petter Selasky <hps@selasky.org> wrot= e: >>>>=20 >>>> Hi, >>>>=20 >>>> If the fallouts could be better organized through some simple guideline= s, t >>> hat would be more accepted I think: >>>>=20 >>>> 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. >>>>=20 >>>> 2) Organize big changes going into the kernel, to ease debugging and ge= ttin >>> g things back on track again. >>>>=20 >>>> 3) If your patch is risky, commit it on a Monday. Don't wait until Frid= ay. >>>>=20 >>>> Failure to follow the rules may have consequences like other senior dev= elop >>> ers kicking in and doing temporary reverts until issues are resolved. >>>=20 >>> Agreed. There???s a reason why at my most former job (FB) we generally k= new b >>> etter than to commit code on a Friday. It would cause the weekend oncall= s a l >>> ot of grief. >>>=20 >>> Let???s put it this way: think of it like being oncall for code. If you d= on?? >>> ?t have someone else to work with who can manage it, would you like to b= e pag >>> ed if something went south with your code committed on a Friday? >>=20 >> This is a good idea. Pinging someone to provide backup support is a good=20= >> idea. phk@ has asked me in this regard once giving me authority to back o= ut=20 >> his commit should it cause any grief. It didn't break anything but he mad= e=20 >> contingency plans just in case. >=20 > All of these can be codified into "operational suggestions" and added to t= he > committers guide, and does not necessarily need to be rules, policy or=20 > 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=E2=80=99s implemen= ted in a structured process, so I don=E2=80=99t have to look up the committe= r=E2=80=99s guide to figure out what the rules are, then apply them. -Enji=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?911BCF8B-CF37-48A5-B3FE-B5959575A996>