From: David Kastrup <dak@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: Messing with the VC history
Date: Tue, 18 Nov 2014 08:42:02 +0100 [thread overview]
Message-ID: <87mw7phs51.fsf@fencepost.gnu.org> (raw)
In-Reply-To: 85ppcl6knw.fsf@junk.nocrew.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
next prev parent reply other threads:[~2014-11-18 7:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 6:17 Messing with the VC history Óscar Fuentes
2014-11-16 8:19 ` Achim Gratz
2014-11-16 15:25 ` Eli Zaretskii
2014-11-16 16:00 ` David Engster
2014-11-17 16:48 ` Eli Zaretskii
2014-11-16 16:33 ` Achim Gratz
2014-11-16 18:13 ` Eli Zaretskii
2014-11-22 10:04 ` Steinar Bang
2014-11-16 15:24 ` Eli Zaretskii
2014-11-16 16:05 ` Óscar Fuentes
2014-11-16 16:21 ` Eli Zaretskii
2014-11-16 23:33 ` Stephen J. Turnbull
2014-11-17 1:31 ` John Yates
2014-11-17 3:23 ` Stephen J. Turnbull
2014-11-18 7:18 ` Lars Brinkhoff
2014-11-18 7:42 ` David Kastrup [this message]
2014-11-18 7:53 ` Stephen J. Turnbull
2014-11-18 8:41 ` David Kastrup
2014-11-18 16:47 ` Barry Warsaw
2014-11-18 17:06 ` Andreas Schwab
2014-11-18 22:30 ` Stephen J. Turnbull
2014-11-19 2:34 ` Stefan Monnier
2014-11-17 16:42 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mw7phs51.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.