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: Patch queue management systems Date: Sat, 06 Dec 2014 12:08:48 +0200 Message-ID: <83fvct145r.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1417860534 3026 80.91.229.3 (6 Dec 2014 10:08:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Dec 2014 10:08:54 +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 Sat Dec 06 11:08:46 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 1XxCI9-0001Bk-QZ for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 11:08:46 +0100 Original-Received: from localhost ([::1]:53921 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxCI9-0001Bo-9B for ged-emacs-devel@m.gmane.org; Sat, 06 Dec 2014 05:08:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxCI0-00014l-Rg for emacs-devel@gnu.org; Sat, 06 Dec 2014 05:08:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxCHv-0002Mg-FT for emacs-devel@gnu.org; Sat, 06 Dec 2014 05:08:36 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:39155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxCHv-0002Ll-7O for emacs-devel@gnu.org; Sat, 06 Dec 2014 05:08:31 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NG500500N5IT400@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 06 Dec 2014 12:08:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NG5005XGO65OG80@a-mtaout23.012.net.il>; Sat, 06 Dec 2014 12:08:29 +0200 (IST) In-reply-to: <86mw71pl6d.fsf@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:179129 Archived-At: [Moved the discussion to emacs-devel.] > From: Dmitry Gutov > Date: Sat, 06 Dec 2014 04:27:22 +0200 > > Stefan Monnier writes: > > > Because nobody has set such a thing up (and AFAICT Savannah doesn't > > have such a thing built-in, oddly enough). > > It shouldn't be too hard, actually, to set up some code review tool, > such as Gerrit [0], Review Board [1] or Differential [2]. I took a quick look at these. 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). . The tools require non-trivial changes in the workflow advertised on the Wiki. E.g., Gerrit requires to work with magic local branches and detached heads. We should carefully evaluate this and decide how to make sure this won't trip those of us who are less proficient in Git (which, judging by the current traffic on emacs-devel, seems like a rule rather than exception) and cause corruption of the upstream repository. There are also other minor issues we need to figure out: licenses, the underlying infrastructure (e.g., AFIU, Phabricator requires PHP), etc. 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. Being an efficient patch reviewer requires good knowledge of at least a few areas of the Emacs core, and we currently have only a handful of people who can qualify. (The obvious exception from this rule is a maintainer of a single package who can review patches for his/her package.) From experience of other projects, 5 reviewers is not enough for this task. So we are again back to the hardest problem in Emacs development: the extremely small number of core maintainers. > I'd also welcome opinions from people who have experience working with > them Seconded.