From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Development suggestions from an ENSIME developer Date: Fri, 22 Jul 2016 09:35:41 -0400 Message-ID: References: <87wpke3kdj.fsf@russet.org.uk> <83h9biyek4.fsf@gnu.org> <877fce3flr.fsf@russet.org.uk> <83d1m6xint.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469194569 25976 80.91.229.3 (22 Jul 2016 13:36:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Jul 2016 13:36:09 +0000 (UTC) Cc: emacs-devel@gnu.org, Phillip Lord To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 22 15:36:01 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 1bQacP-0001lJ-LU for ged-emacs-devel@m.gmane.org; Fri, 22 Jul 2016 15:35:57 +0200 Original-Received: from localhost ([::1]:47253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQacO-0006Ea-Ib for ged-emacs-devel@m.gmane.org; Fri, 22 Jul 2016 09:35:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQacH-0006EV-GJ for emacs-devel@gnu.org; Fri, 22 Jul 2016 09:35:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQacF-0001MO-Da for emacs-devel@gnu.org; Fri, 22 Jul 2016 09:35:48 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQacA-0001Kn-69; Fri, 22 Jul 2016 09:35:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+FgA731xV/3mcpUVcgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQSFBgNJIg3CM8jAQEBBwIgizqEIhEBUQeELQWfF44Wg36CFIFFI2GBBYIuIoE0BwIXgSQBAQE X-IPAS-Result: A0A+FgA731xV/3mcpUVcgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQSFBgNJIg3CM8jAQEBBwIgizqEIhEBUQeELQWfF44Wg36CFIFFI2GBBYIuIoE0BwIXgSQBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="248873617" Original-Received: from 69-165-156-121.dsl.teksavvy.com (HELO pastel.home) ([69.165.156.121]) by ironport2-out.teksavvy.com with ESMTP; 22 Jul 2016 09:35:42 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 19B6064CAC; Fri, 22 Jul 2016 09:35:41 -0400 (EDT) In-Reply-To: <83d1m6xint.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Jul 2016 09:59:18 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:206023 Archived-At: > The number of manual actions one needs to do when processing a patch > can be counted, and the counts can be compared. The "normal" speed of > each operation can also be measured. So I see no issues of coming up > with a more-or-less objective assessment of the proposed workflow vs > the existing one. I think in the best-case scenario, a merge-request system won't help very much 1a- You look at the patch in your email 1b- You look at the patch in your the MRS 2a- You think it looks good 2b- You think it looks good 3a- You M-| it to "git am; git push" 3b- You accept the request But in my experience, step "3a" all too often doesn't work out so nicely, because the patch is not quite in the right format. With some luck it's been word-wrapped or worse. In practice I find "3a" to be surprisingly time-consuming. The merge-request flow avoids those pitfalls. Also, the "1a" step can be fairly different from "1b" because the tool knows it's a patch, it knows against which branch in which repository it applies, etc... so "1a" can precompute specialized extra info, such as: - the result of a tentative build (compilation warnings and regression tests, tho that depends on having such a system setup and having the resources to run it for every merge-request (and every update of it)). - a diff w.r.t the previous version of that same merge request. - info about the fact that the patch doesn't apply against "master" any more. - hopefully/ideally the tool could have already checked copyright.list for you. - ... Depending on the actual tool you end up using and other considerations, an MRS can also offer further advantages (don't know enough about Kallithea nor Gitlab to know if they offer those features): - "3b" can just mark the request as "reviewed by ", so you can give "half-commit" rights to some users. - it sometimes makes it easier for 3rd parties (or for the reviewer) to update the merge request directly (instead of adding comments). Of course, there's also the effect on the side of the patch-submitters, where the precise flow is often made easier for them because there's no doubt about where to send the patch, in which format, etc... Stefan