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 22:57:46 +0300 Message-ID: <83eg75jk5h.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> <837fcxlbay.fsf@gnu.org> <87lh1d2wg5.fsf@russet.org.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1467921500 16173 80.91.229.3 (7 Jul 2016 19:58:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2016 19:58:20 +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 21:58:16 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 1bLFR9-0006Yg-Aj for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 21:58:15 +0200 Original-Received: from localhost ([::1]:42015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLFR8-0002sG-A2 for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 15:58:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLFQy-0002qj-QY for emacs-devel@gnu.org; Thu, 07 Jul 2016 15:58:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLFQv-0003GJ-Ix for emacs-devel@gnu.org; Thu, 07 Jul 2016 15:58:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLFQv-0003Fu-FU; Thu, 07 Jul 2016 15:58:01 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2181 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bLFQt-0000s0-Ke; Thu, 07 Jul 2016 15:58:00 -0400 In-reply-to: <87lh1d2wg5.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:205375 Archived-At: > From: phillip.lord@russet.org.uk (Phillip Lord) > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Thu, 07 Jul 2016 18:24:10 +0100 > > First, we do not have a system for managing PRs/patches in the > queue. So, it's possible that people with outstanding patches are > not busier than you, they just missed things. I just read the bug list and manage my email queue. How hard can that be? > Secondly, in terms of pushing patches for someone else, this doesn't > need to be harder than reviewing the patch and signaling that you are > happy. Many PR management systems will do the merge after "LGTM". Problem is, I don't find the subtle fine points that need addressing until I actually apply the patch: compiler warnings, code not according to our conventions, sometimes patch won't apply, etc. > I look at this the other way around. I think we are likely to get more > developers, if it is easier to contribute. I think we've already done a lot in that direction, and I don't see how can we be expected to do more. All the other projects I participate in make it harder, and yet no one complains or thinks they are hard on contributors. > A project where you can send in a patch, and have some one give you > feedback on it, will end up with more developers. Which is exactly what I said, and you objected. So now I'm confused what we are arguing about. > >> 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? > > I think I have discussed this with you before. You have to create > multiple feature branches, or do strange things, rather than just > rebase, force push. What's the problem with multiple branches? It's a very easy technique, and also very safe.