FCP 20190401-ci_policy: CI policy

Warner Losh imp at bsdimp.com
Fri Aug 30 00:19:16 UTC 2019


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

> >> 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.
>
> Fair enough, right now the policy needs to accommodate the reality of
> the tools we're using today.
>
> Perhaps it's a failure of imagination on my part but I have trouble
> seeing how a revert would lead to losing work - could you give an
> example?
>

I've twice lost work due to a hasty reversion in the past. In my case, when
I did the svn update it ended badly due to the conflicts that were
generated. Most of the times I've hit conflicts in the past, it's just been
the work of a conflict. When the work was larger, svn got a bit confused
and I wound up losing several chunks of work. I was able to redo it, but it
was annoying. It's why a super-fast automatic revert without contact with
the person that committed it is a bad idea. Of course, if that person falls
down in fixing it, I support doing something. Tools have improved, and
perhaps this is a case of once bitten twice shy...


> > 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.
>
> The level of effort imposed on other users while the tree is broken is
> not zero, either. Certainly if it's possible to commit a fix and move
> forward that's the approach favoured by community norms.
>

I agree. My pushback here is against the notion there's zero cost to a
revert. Of course we need balance the damage to others vs the impact on the
contributor. When the impact is in -current on a fringe platform, we need
to not over-react to fixing that by back out.


> > 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...
>
> The point of the FCP is to facilitate the revert while the change is
> (among the) most recent, precisely so that additional changes don't
> build on it.
>

Agreed. I just don't want to swing too far to the automatic end of things,
and to apply some level of judgement when there's more than one change
involved.

Warner


More information about the freebsd-fcp mailing list