FCP 20190401-ci_policy: CI policy

Warner Losh imp at bsdimp.com
Thu Aug 29 23:35:44 UTC 2019


On Thu, Aug 29, 2019, 5:27 PM Ed Maste <emaste at freebsd.org> wrote:

> On Thu, 29 Aug 2019 at 17:32, Warner Losh <imp at bsdimp.com> wrote:
> >
> > In the past, if someone had any follow on work at all in their tree, the
> > reversion would be quite disruptive to that work.
>
> This sounds more like a problem with the tooling than an argument
> against reverting though.
>

We live in a subversion universe for the moment, so you have to view it
through that lens.

I agree that in the case where the fix is straightforward it's
> sensible, and in line with community norms, to just commit it. But in
> the case that a regression was introduced by a committed change,
> modern tools facilitate reverting and replaying changes without a lot
> of effort.
>

Sometimes yes, sometimes no. Even with git svn, there is a cost
associated with it.  The level of effort is not zero. Especially when one
pushes several interrelated changes at once. If the first of these caused
an issue on gcc, say, often the cost is too high to revert the whole chain.
It's a lot easier to put in a fix and move on.

> things quickly, imho, to hesitate a little on the revert. Especailly when
> > the broken thing is the playstation loader on powerpc that can stay
> broken
> > for the hour or six (or even days) it takes me to figure out why it
> > broke... Often things away from the beaten path don't get discovered for
> > days or weeks or months, and a reversion then can be extremely disruptive
> > if there's other changes layered on top of the offending commit....
>
> Note that this isn't at all the issue under discussion in the FCP,
> which refers to issues that have already been detected by CI. For
> example, a commit which means amd64 panics on boot. Reverting quickly
> is a benefit in this sort of case found by CI precisely so that we
> don't end up with other changes on top that are difficult to unwind.
>

It's a fair example for why a simpleminded approach will create more
friction than the current system. And there is a need for caution in
expanding the logic beyond all but the most recent changes...

Warner

>


More information about the freebsd-fcp mailing list