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: Patch queue management systems Date: Tue, 09 Dec 2014 19:09:26 +0200 Message-ID: <83iohkwy0p.fsf@gnu.org> References: <546D2E75.6090701@cs.ucla.edu> <837fyp7tvi.fsf@gnu.org> <546E2899.4050702@cs.ucla.edu> <54756754.5090103@cs.ucla.edu> <54762721.4060908@cs.ucla.edu> <17zjb2h650.fsf@fencepost.gnu.org> <86mw71pl6d.fsf@yandex.ru> <83fvct145r.fsf@gnu.org> <5486F304.9030101@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418145014 14860 80.91.229.3 (9 Dec 2014 17:10:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2014 17:10:14 +0000 (UTC) Cc: eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 09 18:10:03 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 1XyOIT-0001Ei-3C for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 18:10:01 +0100 Original-Received: from localhost ([::1]:41537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyOIS-0004ss-6c for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 12:10:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyOI9-0004s1-Uc for emacs-devel@gnu.org; Tue, 09 Dec 2014 12:09:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyOI5-0003Mb-8V for emacs-devel@gnu.org; Tue, 09 Dec 2014 12:09:41 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:37263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyOI4-0003M9-RX for emacs-devel@gnu.org; Tue, 09 Dec 2014 12:09:37 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NGB00L00R7ME600@mtaout29.012.net.il> for emacs-devel@gnu.org; Tue, 09 Dec 2014 19:07:15 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGB00DDLRK0YL80@mtaout29.012.net.il>; Tue, 09 Dec 2014 19:07:15 +0200 (IST) In-reply-to: <5486F304.9030101@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 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:179575 Archived-At: > Date: Tue, 09 Dec 2014 15:03:00 +0200 > From: Dmitry Gutov > CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org, eggert@cs.ucla.edu > > On 12/06/2014 12:08 PM, Eli Zaretskii wrote: > > > I think by far the 2 main issues we will have with these tools are: > > > > . The tools don't have Emacs integration built into them, nor offer > > Emacs VC sub-modes. (Gerrit has a magit plugin.) I'm guessing we > > would like to arrange for such an integration in VC, because people > > who review patches are accustomed to using Emacs and have elaborate > > customizations for this that they would lose if the review is only > > done via a Web browser (even if that browser is eww). > > Looking at magit-gerrit, it's not that big. If you're okay with that > level of integration, it shouldn't take too much work, as long as the > review system comes with a command-line tool or an API (which, of > course, will be a requirement). Magit is not part of Emacs. I think we would like this to be integrated into VC. > > Personally, I think arranging the development around this kind of > > process will not work without some critical mass of patch reviewers > > who are able to endure the current constant high volume of changes, > > let alone if we want to increase that volume. > > Right, but that's only if/when we decide to push all contributions > though this system. We could start light, and continue allowing > committing directly to the repository, but move the > patches-to-be-discussed (which will take up reviewers' time anyway) to > the new system. I'm not sure such a split process makes sense. It will complicate procedures and most probably cause some patches fall through the cracks. > On the other hand, if we want to use this to guarantee quality of commit > messages, a review process in some form will be required anyway, but > since a lot of focus would be on the form rather than substance, not > every reviewer would have to be intimately familiar with the area of the > code they're reviewing. I think comments about the form are usually the easiest part of the review, and some of that can be automated. Also, some form-related issues are actually derived from familiarity with Emacs design and implementation. So yes, we could have "junior reviewers" who'd only deal with form issues, but that would off-load only a minor portion of the work required to do this.