FCP 20190401-ci_policy: CI policy

[Warner Losh]

On Thu, Aug 29, 2019 at 3:26 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Thu, Aug 29, 2019 at 1:05 PM Rodney W. Grimes <
> freebsd-rwg at gndrsh.dnsmgr.net> wrote:
>
>> (unneeded context removed)
>>
>> > > In either scenario we end up reducing test coverage, which means we?re
>> > > going to push more bugs towards users.
>> > >
>> > > > I totally agree.  This is an overly-bureaucratic solution in search
>> of
>> > > > a problem.
>> > > >
>> > > > If this needs to be addressed at all (and I'm not sure it does),
>> then
>> > > > another sentence or two in bullet item 10 in section 18.1 [*] of the
>> > > > committer's guide should be enough.  And even then it needn't be
>> > > > overly-formal and should just mention that if a commit does break
>> the
>> > > > build the committer is expected to be responsive to that problem and
>> > > > the commit might get reverted if they're unresponsive.  I don't
>> think
>> > > > we need schedules.
>> > > >
>> > > I do feel that?s a better argument. We?ve always had a policy of
>> > > reverting on request (AIUI), so this is more or less trying to be a
>> > > strong restatement of that, more than a fundamental shift in policy.
>> > >
>> >
>> > We don't have a policy to revert commit, actually revert commit is
>> > something bad, it is kind of punishment, I have been there, nobody
>> wants to
>> > be there. Stop to push this non-sense argument.
>>
>> Here in lies one of the fundemental problems, this view by some that
>> a "revert commit is something bad, it is kind of punishment".  That is
>> not true.  Reverts are GREAT things, they allow the tree to be returned
>> to a known state, usually quicly.  The original commit is STILL IN SVN,
>> and a bad revert can guess what.. be reverted!.
>>
>> IMHO the project as a whole needs to overcome its fear of reverts and
>> start to use them for the great and powerful things that they are.
>>
>> This connection of bad and punishment needs to stop, and the sooner
>> the better.
>>
>
In the past, if someone had any follow on work at all in their tree, the
reversion would be quite disruptive to that work. Most of the time it's a
lot easier for me, with a lot less friction, to just fix issues that come
up after the commit than to revert and prepare a new commit. Sure, it's
possible, but it can destroy work in extreme cases. *THAT* is why I'm
firmly in the camp of giving the original committer a shot at fixing things
because it's much less disruptive to them, and generally we can get a fix
into the tree faster. It reduces friction and encourages people to fix
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....

So the whole reversion issue is a lot more complicated than 'oh, it's still
in svn'. There are real high costs associated with being too quick or
liberal on the revert and those must be weighed against the damage the bad
commit is doing..

Warner