From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Messing with the VC history Date: Tue, 18 Nov 2014 08:42:02 +0100 Organization: Organization?!? Message-ID: <87mw7phs51.fsf@fencepost.gnu.org> References: <87k32vsm8u.fsf@wanadoo.es> <83fvdjdv8t.fsf@gnu.org> <871tp3rv07.fsf@wanadoo.es> <87lhnavhz9.fsf@uwakimon.sk.tsukuba.ac.jp> <87ioiev7bp.fsf@uwakimon.sk.tsukuba.ac.jp> <85ppcl6knw.fsf@junk.nocrew.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416296560 19685 80.91.229.3 (18 Nov 2014 07:42:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 07:42:40 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 08:42:33 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XqdQm-0004tz-Ku for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 08:42:32 +0100 Original-Received: from localhost ([::1]:51684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqdQm-0001w8-Aq for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 02:42:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqdQd-0001vp-BJ for emacs-devel@gnu.org; Tue, 18 Nov 2014 02:42:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqdQX-0005cc-C0 for emacs-devel@gnu.org; Tue, 18 Nov 2014 02:42:23 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:50758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqdQX-0005cQ-5Y for emacs-devel@gnu.org; Tue, 18 Nov 2014 02:42:17 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XqdQU-0004oQ-RF for emacs-devel@gnu.org; Tue, 18 Nov 2014 08:42:14 +0100 Original-Received: from x2f41f1e.dyn.telefonica.de ([2.244.31.30]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Nov 2014 08:42:14 +0100 Original-Received: from dak by x2f41f1e.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Nov 2014 08:42:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 68 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f41f1e.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:2RsHexreQPBOSIl+c589v9FF2LE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177521 Archived-At: Lars Brinkhoff 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