[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: FCP 20190401-ci_policy: CI policy
From:       Enji Cooper <yaneurabeya () gmail ! com>
Date:       2019-09-03 21:16:30
Message-ID: 911BCF8B-CF37-48A5-B3FE-B5959575A996 () gmail ! com
[Download RAW message or body]

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.

-Enji
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


[prev in list] [next in list] [prev in thread] [next in thread]