From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Fri, 02 Dec 2016 12:56:15 +0200 Message-ID: <83wpfimwfk.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480676208 17048 195.159.176.226 (2 Dec 2016 10:56:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 10:56:48 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 11:56:43 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cClWD-000377-3J for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 11:56:41 +0100 Original-Received: from localhost ([::1]:33765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cClWG-0007qu-LD for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 05:56:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cClVj-0007qd-4S for emacs-devel@gnu.org; Fri, 02 Dec 2016 05:56:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cClVf-0007nd-12 for emacs-devel@gnu.org; Fri, 02 Dec 2016 05:56:11 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cClVe-0007nZ-Tx; Fri, 02 Dec 2016 05:56:06 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1490 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cClVe-0006U2-71; Fri, 02 Dec 2016 05:56:06 -0500 In-reply-to: (message from Philippe Vaucher on Fri, 2 Dec 2016 10:00:28 +0100) 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:209914 Archived-At: > From: Philippe Vaucher > Date: Fri, 2 Dec 2016 10:00:28 +0100 > Cc: Stefan Monnier , Emacs developers > > Once again, if those ideas seem strange, let alone incorrect, to > you-all out there, just say the word, and I will step down. Then I > can stop worrying about the portable dumper, and you can stop worrying > about my strange ideas. Emacs is not my private project; I'm only > entitled to promote my ideas if the others either support them or > trust me to DTRT. Please decide which one is it, and let's move on. > > Eli, I think you are doing a fantastic job. > > The only problem that seems to happen from time to time is that the discussions starts getting personal and > ends up with people saying threats like "if you put my code in a branch I will fork Emacs" or "if you don't agree > with my ideas I will step down", which is just a way of saying "my way or the highway". Using these rethorics > is not constructive and doesn't do anyone any good. What do you expect me to do when I see code which takes Emacs in a direction I think is wrong? There are a very few of such directions I feel strongly we shouldn't take. What am I supposed to do when I see one of them proposed for inclusion? More generally, is the maintainer allowed to reject some code or course of actions? If yes, what are the criteria for that? > To Daniel, it's important that his work does not bitrot somewhere like the concurrency branch did. It's also > important that he feels there's a strong chance of his code getting merged before he works more on it. > To Eli, it's important to have Daniel's code more "production ready" (documentation, etc), and also to give the > simpler implementation ideas a try to avoid having to switch/maintain different systems twice in a short period > of time. No, you've misunderstood the nature of our disagreement. There's no disagreement about the code being production-ready: Daniel himself said it isn't yet. > Daniel, we'll give other people one month to come up with a sketch of the alternative idea to see if it's > feasible or not. If nothing comes up after one month, we'll start working on merging your branch. That's what I said, with the exception of the "month" part. If we are talking about better communications, then I can suggest discussing an idea before it is coded. As a matter of fact, I proposed a very similar idea 2 months ago, and it was voted down by Paul, so I didn't pursue it, also because that discussion brought up the "one large .elc file" idea, which Paul liked better (and so did I), the only issue with it being the performance that we could get. If Daniel have described his idea before coding it, I think at least some of the aggravation (mine included) could have been spared.