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: Is it time to drop ChangeLogs? Date: Thu, 07 Jul 2016 18:25:57 +0300 Message-ID: <837fcxlbay.fsf@gnu.org> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <87twg2g86g.fsf@lifelogs.com> <83eg76n5h5.fsf@gnu.org> <87y45eeoor.fsf@lifelogs.com> <577D42BB.1020500@cs.ucla.edu> <87oa694rfw.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1467905254 14519 80.91.229.3 (7 Jul 2016 15:27:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2016 15:27:34 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 07 17:27:33 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 1bLBDA-0000Of-MZ for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 17:27:32 +0200 Original-Received: from localhost ([::1]:40616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLBDA-0001PK-3m for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 11:27:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLBBw-0000KU-GD for emacs-devel@gnu.org; Thu, 07 Jul 2016 11:26:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLBBr-0008Ef-A4 for emacs-devel@gnu.org; Thu, 07 Jul 2016 11:26:15 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56282) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLBBr-0008EW-6x; Thu, 07 Jul 2016 11:26:11 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1848 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bLBBp-0005zR-5j; Thu, 07 Jul 2016 11:26:09 -0400 In-reply-to: <87oa694rfw.fsf@russet.org.uk> (phillip.lord@russet.org.uk) 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.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:205339 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Date: Thu, 07 Jul 2016 12:29:23 +0100 > Cc: emacs-devel@gnu.org > > - I can push a branch onto the Emacs git. But, this is not squashable, > so the final state before the merge is hard to do > - There is no system for queuing pull requests, so sometimes things get > forgotten > - I can send patches, but this is clunk compared to pushing a branch > within version control. > - There is no system for viewing feedback about an individual patch. > - There is no system for adding inline comments to patches This will continue to be like that as long as we don't have enough core developers who understand enough of Emacs and can be trusted to approve changes. When (if) we do have enough of them, patches submitted to our 2 lists will be reviewed in time, and most of the above will just go away without a trace. Starting a PR system in the current conditions is just going to _increase_ the workload of the few overloaded people. E.g., I don't want to push changes for anyone else, ever: it takes too much of the little time I have to work on Emacs. I want this burden off-loaded to someone else. Guess what? patches that I said were okay can rot for many days without anyone with write access doing anything. I can only conclude they all are as busy as I am or busier. As long as this is the situation, how could a PR system help, when it requires me to do _more_ than I have to now? > Installing something like gerrit or kallithea would be nice (I have no > direct experience of using either, but they are similar to other > systems). However, this would be considerable work. Exactly! > Perhaps, as a half way house, we could use the resources that we have. > PRs could go to the bug reporting system. This will, at least, keep all > the conversations in one place. If we can tag these with "has patch" > here as well, it will give an queue also. We already try doing that, as much as we can. Fortunately, a few people lately started actively reviewing bug reports, both old and new, and post analyzes, tag them, propose patches, etc. That's great, but we need more of them, and we need to wait for them to gain enough knowledge and experience to be able to overlook larger portions of Emacs (including the parts written in C, btw). This should be the main vector of our process improvement, at least for some time to come. Because nothing more substantial can happen until we have a critical mass of active maintainers. > We would still need to do something about the Emacs git, in terms of > squashability; in practice, this would probably require something > like gitolite as allowing non-FF pushes on all branches would be a > bad thing. I don't really see a problem. Why doesn't a feature branch or a scratch branch solve all of this nicely and easily?