FCP 20190401-ci_policy: CI policy

[Cy Schubert]

In message <8350379A-30F8-4BBD-B9AE-A3A176CAE966 at gmail.com>, Enji Cooper 
writes
:
> 
>
> > On Sep 1, 2019, at 10:42 AM, Hans Petter Selasky <hps at 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 at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.