Re: Messing with the VC history

[David Kastrup <dak@gnu.org>]

Lars Brinkhoff <lars@nocrew.org> writes:

> Stephen J. Turnbull wrote:
>> John Yates wrote:
>>  > Stephen J. Turnbull wrote:
>>  > > Some dislike rebasing in principle or because doing it properly
>>  > > (as they understand it) involves running tests on all rebased
>>  > > commits.
>>  > 
>>  > Are they under the impression that by contrast a merge absolves
>>  > them of any need to run tests?
>>
>> Of course not!  They know for a fact that they already ran them on
>> the revisions in their feature branch and on the merged code, and
>> that the rebased revisions will be *different* from the revisions
>> they ran tests on.  They object to running the tests *twice* when
>> once should do.
>
> I've met some of those.  Is there a counterargument?

After having repeated moments of tension with a non-workable master,
LilyPond moved to a different setup.  "Check that everything builds,
including the documentation" takes more than an hour on my system, a
moderately up-to-date dual processor machine.  We have contributors with
considerably less machine power.  We have a few volunteers with
considerably more.

Prospective patches are sent to a tracker.  Volunteers regularly pick
them up with an automated procedure, run all regtests and view the
flagged visual differences in the regression tests and logs and
(weighted and thresholded) memory usage statistics.  The last step of
viewing the differences is manual and making a comment/judgment is
manual, the rest automatic.  So all patches have seen testing against
_some_ version of LilyPond.

When committing any commit, it is committed to a branch called
"staging".  NO HUMAN COMMITS TO MASTER.  staging is picked up regularly
by an automated process, compiled, regtest-checked (without visual
comparison), documentation and translations built (includes all the web
sites).  If compilation completes successfully, the result is pushed to
master.

This automated process can fail for a number of reasons.  Mails get sent
out without stopping the scheduled attempts.

Those reasons are: failure (of course).
master cannot be fast-forwarded to staging (some human pushed to master,
or a staging test run on another machine with a conflicting staging
branch completed first): may need manual fixing
the tested staging is not strictly behind the upstream staging at the
time testing completes: that means that somebody cleared staging and
replaced it by something else while testing progressed: an emergency
stop if you find you pushed something bad and noticed immediately: in
that case resetting staging is enough to stop the automated run from
pushing the no-longer-accepted version of staging even if it tests fine.

The "who messed up master?" panics have gone.  Actually, the frequency
of messups overall has not been a lot recently, but "staging is messed
up" is a comparatively harmless problem.  It halts the queue.  It's only
messy when you have a lot of different contributions queued in staging
and one is bad.  However, the frequency of the automated runs make this
unlikely, and you can always wait for the queue to clear a bit if you
are not really sure your change is good and want to save others from
having to recommit and/or substitute a rebased version of staging with
your bad commits removed.

-- 
David Kastrup