From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Code reviews (was: Is it time to drop ChangeLogs?) Date: Tue, 08 Mar 2016 17:54:36 +0200 Message-ID: <83oaaprmmb.fsf@gnu.org> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <87vb4zb0i4.fsf@gnu.org> <837fheuu6a.fsf@gnu.org> <877fheb1rh.fsf@wanadoo.es> <87ziua9mwq.fsf@wanadoo.es> <83h9git36k.fsf@gnu.org> <87vb4y9ep9.fsf@wanadoo.es> <83a8mat2aa.fsf@gnu.org> <87r3fm9du0.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457452495 13229 80.91.229.3 (8 Mar 2016 15:54:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2016 15:54:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 08 16:54:50 2016 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 1adJy3-0005f2-TH for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 16:54:40 +0100 Original-Received: from localhost ([::1]:35473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJy0-0000jd-2M for ged-emacs-devel@m.gmane.org; Tue, 08 Mar 2016 10:54:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJxw-0000jG-DE for emacs-devel@gnu.org; Tue, 08 Mar 2016 10:54:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adJxs-0005yk-FL for emacs-devel@gnu.org; Tue, 08 Mar 2016 10:54:32 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adJxs-0005yg-Bj; Tue, 08 Mar 2016 10:54:28 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2697 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1adJxr-0003pU-KQ; Tue, 08 Mar 2016 10:54:28 -0500 In-reply-to: (message from Stefan Monnier on Mon, 07 Mar 2016 22:25:12 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:201155 Archived-At: > From: Stefan Monnier > Date: Mon, 07 Mar 2016 22:25:12 -0500 > > If we could switch to a system where every patch is reviewed before > commit, that'd be great. My own impression is that it will kill the > development pace because too few people are willing to spend the > corresponding efforts. Agreed. For my part, I can say that I simply don't have enough free time to review more patches than I do (which is an abysmal little). > That's why I've followed a practice of giving out write access very > liberally, with "post-commit spot-check reviews" instead. Indeed, it > means that errors in commit messages can't be fixed (we can fix them in > the ChangeLog files, admittedly, but since I don't use them it doesn't > help me). Post-commit reviews also take time. Do you have an estimation of how much time per day this takes? > Maybe we could have a half-way system, where commits are pushed to > a branch that is "not fast-forward-only", and this branch is then > auto-merged to the real (fast-forward-only) master branch after a delay > (one day, maybe?) to give time to fix mess ups before they're cast > in stone. A day is nowhere near enough. IME, a bad commit pushed to master takes up to a week to be discovered. More generally, the problem with such a branch is that it won't be much different from pushing to master, except in rare cases that it breaks the build, and even that can only be avoided if we set up some kind of CI system that continuously builds that branch on the main supported platforms.