FCP 20190401-ci_policy: CI policy

Enji Cooper yaneurabeya at gmail.com
Tue Sep 3 21:16:36 UTC 2019


On Sep 2, 2019, at 08:12, Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net> wrote:

>> 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.
> 
> 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.

-Enji


More information about the freebsd-fcp mailing list