From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Matt Armstrong Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Thu, 01 Dec 2016 01:03:46 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <0839b53b-4607-144f-3746-db054a29c1cd@cs.ucla.edu> <83zikiqdu5.fsf@gnu.org> <834m2orkhn.fsf@gnu.org> <83h96opaye.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480583372 24771 195.159.176.226 (1 Dec 2016 09:09:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 09:09:32 +0000 (UTC) To: Daniel Colascione , Eli Zaretskii , eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 01 10:09:26 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 1cCNMr-00054t-Ny for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 10:09:26 +0100 Original-Received: from localhost ([::1]:49009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCNMs-0005j7-HP for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 04:09:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCNHW-0002Ov-4y for emacs-devel@gnu.org; Thu, 01 Dec 2016 04:03:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCNHU-0005os-4m for emacs-devel@gnu.org; Thu, 01 Dec 2016 04:03:54 -0500 Original-Received: from mail-pg0-x22b.google.com ([2607:f8b0:400e:c05::22b]:33590) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCNHT-0005oK-Rr for emacs-devel@gnu.org; Thu, 01 Dec 2016 04:03:52 -0500 Original-Received: by mail-pg0-x22b.google.com with SMTP id 3so93017271pgd.0 for ; Thu, 01 Dec 2016 01:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=5h/CCd2b09R5tI5v0UjedatyaOe0WrPELo2SHJFEp1A=; b=MmcKA/7D81PXh5s+UHlkq6C0DXH/z1UlP5X56WHKhjZhP/LnGnE1j7S4USPWfUBv5d CNVpQCe5F4ZjNrso6oorH8ALAOlazyQXjXSp0P9PIPaY6Dj1XA7d8mR2fKB4qMz4vpFS kUM8ejkjZ3gn7HbWeRnmS65yoZv/jimkP6ODplZGH0GzwVhrs8XjXpLaTEmDDIlMggHP Ap+HxWDKEe38lIA8419GOXqvif1bPmzqOW72KqeVMk/Pbn6OS4XrB/BBHcVavB7a+TO6 o374j9kmmyfCtMu4XeZc2/RFinksDnseK7hA65tcj7+L1iSwJfSPEGZzjvV935d8baWN BvBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=5h/CCd2b09R5tI5v0UjedatyaOe0WrPELo2SHJFEp1A=; b=XgicYfP5oZNiH3sZqH7FvmJb1DpHH/sMYu7LOeeeToKuHCWMTmoDI3aAp4TcHTCP9V 7y3oAnhrzxNCNA5n9KqtJn9z5j+eGn+o5BK0cEQUdhf/KpKXR//4tM+ef7SMOvegjv5C JdtOjpa/iBu3gxz0V9AfvoRc8HXZN4O6iUalFReXIRIDICv5cyBaIR3UYRupzqPrwM9q vBaJfA+ZshK9cNVccpEnbv7yiVT7KqNAqQaDBMjQ3vP6CwpSIzfOgkNUzwbQjrCLIwp9 f82fJbLJT1iyKfG3nK8K38wObq+7P1JGcXNnfPgLSAgAPzcaAt9I3R3obA4IKlHKwIur smsw== X-Gm-Message-State: AKaTC01UnYkxcnc6vsEz2nM9+FV/zthOFNshFHW92Aq6UJmJw26CK/O2rzOBLCp5ECB2oHUe X-Received: by 10.84.164.106 with SMTP id m39mr81461292plg.97.1480583030117; Thu, 01 Dec 2016 01:03:50 -0800 (PST) Original-Received: from marmstrong-linux.kir.corp.google.com ([2620:0:1008:11:5568:dca:2f4:e0c]) by smtp.gmail.com with ESMTPSA id 65sm108037837pfl.21.2016.12.01.01.03.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 01:03:47 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c05::22b 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:209865 Archived-At: Daniel Colascione writes: > On 11/30/2016 08:49 PM, John Wiegley wrote: >>>>>>> Daniel Colascione writes: >> >>> If that's your decision, I'm going to fork. >> >> I'm quite sorry to hear it, but if branches are unacceptable, then such is >> your right as a free software developer. > > Branches in general are fine. Relegating this specific feature to a > branch feels political. > > I would very much prefer to continue improving GNU Emacs. I'm a longtime > fan of the GNU Project. But I feel like the current gatekeepers are > standing in the way of progress. Hey Daniel, as a mostly-irrelevant observer, I hope you do. I don't have time to devote to Emacs the way you do. I think the best use of my time is to try to convince you to continue doing so, by being as honest as I can. My advice: - take a breath, cool down - give it time, build trust - build on areas of agreement and common interest I'm not an Emacs maintainer, and can't speak as one. But, I play a similar role at work, and can tell you that the technical issues at play in these conflicts you have with Emacs maintainers are secondary. At their core, these discussions are all about trust. You don't fully trust the maintainers, and they don't fully trust you (hopefully "yet" on both accounts). In my "day job" I have the equivalent of "commit rights" to some widely used software critical to the company's function. >From what I see, the role is similar to that of an Emacs maintainer. It is actually more important that the software remain functional and high quality, and healthy for the long term, than it is to optimize development practices for velocity of change. Like Eli, John, and other maintainers, I'm often put in the position of saying "no" or "slow down, I'm not sure yet" to a change. Quite often those asking for the change don't have the same perspective I do. They might see their change as minor. Or critical. Or urgent. Or, if what they introduce incurs some ongoing maintenance cost, they might underestimate that cost, or truly believe in their commitment to bearing that cost for the long term. What they often don't appreciate is that I've seen *all* the failures. I've seen the "simiple risk free idea" break horribly, or later became something we regret. I've seen authors vanish with half finished ideas, leaving the *actual* maintainers with a mess. I've seen "critically urgent" changes become totally unnecessary as easier, more viable alternatives come to light (often only after careful analysis, done by me or others, sometimes to the impatient response of those proposing change). In this kind of system, where there is a hierarchy of decision makers, and quality is often more important than speed, trust is earned over time. The quickest way to build trust is slowly, with a demonstrated willingness and capability to collaborate and be sane over a period of time. Technical merit and an ability to make good logical arguments are also important, but secondary. True technical "arguments" are always boring. They're pure pro/con assessments, dispassionately weighing the knowns, unknowns, risks, etc. Things get "spicy" when it is issues of trust, power, authority, morality, etc. Yet, I think it is human nature to try to "win" such discussions by continuing to appeal to technical issues alone. Quite often, it boils down to "I don't trust you yet" and "Your lack of trust frustrates me". There is no getting around that. A decision being made for "political reasons" is not actually bad, it is the expected norm. As a mater of political strategy, I'd encourage you to view "please commit to a branch" as a victory. Do it and watch trust grow in both directions. It is the foot in the door that gets the project closer to the place you'd like to see it go. It is a strategic move! > Let me try one last time to explain my position: this dumping code > will make no Emacs no worse. It cannot possible destabilize Emacs when > it is compiled out of Emacs at configure-time. I specifically designed > this feature to be optional. I am perfectly happy merging my code in > such a way that it is not compiled into Emacs by default, and I am > perfectly happy waiting until we've gotten sufficient testing before > enabling the portable dumper. First, let me say these your arguments don't strike me as being wildly off base. But, I'm not even an Emacs maintainer and can't help but view the with some suspicion born from the school of hard knocks (see scenarios outlined above). Viewed from my experience, if I pretend to be an Emacs maintainer, this is actually what I end up thinking: - There will be more #ifdefs in Emacs code. - You are not likely to admit it, but you may disappear. If you do, it may be my job to remove the #ifdefs. - You are particularly forceful and invested in getting your way. If I end up saying "no" in the end, you may walk away, leaving me with a mess to clean up. - You are less experienced than the maintainers with the code base, but claim a change is safe/easy/cheap/harmless. That is nice, but I've seen these claims play out differently before. - So, risk is non zero. I'd like to entertain ways to move this forward with less risk. > But because this code is harmless when compiled away and because we > can back it out without problems, I see the requirement that we put > this code into a branch as a way to kill the feature. If this code > were more fundamentally destabilizing, I would feel different --- but > as it is, since this code is *not* fundamentally destabilizing, I > don't see a technical case for a feature branch. The purpose of a branch is to isolate risk. Sure, any branch may never merge back, but the primary reason to commit to a branch is to *facilitate* future code sharing between the branch and mainline, not to kill features. >> Just so you know, I'd hope to see your patches on master within six >> months, > > What specific conditions need to be met before merging? I think asking for a contract is not unfair, but may be unrealistic. Have you seen the green light given to the concurrency branch? That branch began without a contract. Again, from a maintainer's point of view, this kind of contractual question is sometimes unanswerable. The maintainer may simply feel reluctance and not know why. Simply being willing to "play ball" over a period of time, combined with the absence of any better options coming along, can often tip the scale in the "okay to merge" direction. Sometimes people need to actually "see" a diff on their own screens, run the binary themselves, etc., and hear a few positive reports from others they trust, before they're willing to green light something. Emailing a pre-commited patch around is one way to do that, but git was invented to support a better workflow directly. Reluctance on the part of project owners is not inherently bad. I have actually been in the position of apologizing to people after I held off their proposed changes for a long time, only to realize that "they were right all along" and was "obviously the right thing to do" in hindsight. I usually thank them for being patient with my reluctance. In reality, my reluctance is usually good judgment, and has saved more work than it has caused harm. Often, I cannot even initially articulate why an idea gives me pause. Sometimes it comes to me some time after the fact. >> if we can find some willing testers (and one has already stepped >> forward). The only way your changes *wouldn't* land is if a better >> alternative comes along in the meantime -- which, of course, would >> mean we all win. The above is John saying "yes". I can't tell you how many times I've said yes to 95% of a proposal and people walk away because of a minor difference of opinion on a non-essential issue. > What is the fundamental difference between merging this code into > mainline in a disabled-by-default configuration and merging it into a > branch 1) the feature owner (you) absorbs the entire cost of maintaining the branch. The maintenance cost at mainline is zero. There is zero chance of ChangeLog, documentation, NEWS, or any mention of the feature appearing in future snapshots, pretests, releases. As far as I know, there is no #ifdef for Emacs documentation. If the feature is not eventually accepted, the cost of rejecting it is zero. There is no "backing the change out" step. 2) it is easy to review the state of the diff in its entirety against the master at any point. Once merged you're stuck with more primitive tools like grep and git blame. > , except that it's much more convenient to try the feature in the > former case? It is probably worth enumerating the concrete differences. 1) git makes it trivial to check out a branch and build. Playing around with the concurrency branch was pretty easy the time I did it. For the "I want to try this for a day and report back" use case, it is fine. 2) using a feature branch long term *is* harder. Only one can be used at a time (easily), and the feature branch owner must merge from master regularly to keep it relevant. 3) using a branch *combined* with another branch is a pain. If I want to test "concurrency AND portable dumper" I have to merge the two branches myself. There is no correct choice, they are just simple tradeoffs. I see both options as reasonable. If the goal is to collect a small-ish number of "I tried it on platform X and it works" reports, and let the ideas percolate/bake for a time, then a branch makes a lot of sense. If the goal is to get the feature used by as many different people as possible as fast as possible in as many different scenarios as possible, then a branch makes less sense. I'll point out that your reluctance to commit to a branch is about trust and not about the technical issues above: you don't seem to believe John when he says the intent is to facilitate a future merge. >> I don't suppose I can encourage you to maintain your fork within the >> Emacs.git repository? There this thing, rhymes with "blanch", where >> you could work on your version in tandem, even merge changes from us >> every once in a while... :) > > There have been cries to adopt a more modern development style, one > focused on GitHub and pull requests. I can certainly accommodate. I do agree that submitting patches to projects on "non github" systems is beginning to feel archaic. I hope the era of emailing patches around disappears. If this is a detractor for Emacs it is also a detractor for every project hosted on savannah.gnu.org. Rather than fork Emacs to github to get the "modern" development style, the greater impact, in terms of benefit to GNU, is adding the desired features to savannah. I don't know if anybody is working on this or not. That said, I think you're too quick to suggest forking Emacs. You'll get more done working with Emacs folks than in spite of them, and the stuff you work on will have more impact. Even if it feels to you like you could go 10x faster alone, building a real community is pretty hard, and you'd be at high risk of burn out doing it alone, and the final product may not result in more than another non-standard Emacs that gets little use.