From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Have you all gone crazy? Was: On being web-friendly and why info must die Date: Sat, 20 Dec 2014 23:18:14 -0600 Message-ID: <87zjah7f8p.fsf@floss.red-bean.com> References: <87388bnzha.fsf@newcastle.ac.uk> <87k31mdbhe.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1419139131 11925 80.91.229.3 (21 Dec 2014 05:18:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Dec 2014 05:18:51 +0000 (UTC) Cc: Phillip Lord , "Allen S. Rout" , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 21 06:18:44 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 1Y2Yug-0001od-9S for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2014 06:18:42 +0100 Original-Received: from localhost ([::1]:36524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2Yuf-00084E-Ky for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2014 00:18:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2YuN-000844-18 for emacs-devel@gnu.org; Sun, 21 Dec 2014 00:18:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2YuH-0006LC-HK for emacs-devel@gnu.org; Sun, 21 Dec 2014 00:18:22 -0500 Original-Received: from mail-yk0-x235.google.com ([2607:f8b0:4002:c07::235]:34272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2YuH-0006L8-Bs for emacs-devel@gnu.org; Sun, 21 Dec 2014 00:18:17 -0500 Original-Received: by mail-yk0-f181.google.com with SMTP id 142so1458424ykq.12 for ; Sat, 20 Dec 2014 21:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=VS5l9I2ADAFigRuHJ+A+mzf0wRlbO8XnYfS4kWFnSm0=; b=AL0Vz+JWuar0eFFkXTCVKYrzjb5aM2LQIGer3olJAuO19pWe737+U63sJRhOn/3PFv LSQSW5Dt8AP3Wr+UYXn0uZyNRf0vKs2Fujw6HsDd89vEFDdxYY+ic13UkW7DvoCMjghd JziTQRRJ/qhg0VZR4fq1+P+9mwXKuX2Isirnvkk1Nfidm91NIGmqa8KbQCfSB5gTDfa9 CkbZeT7QIXnsK3CJuiDcaRSSXDW69EP5VItx2AahenLfqyiCqXyRCHW9z8m0xo7sTp2e ZWy5rsX1ulRKuwdtZ4gLD8YOyjcSyEqRFDgkRZEreAR9aAxuH90ss/DGQHY0VUCqqMTy +S2w== X-Received: by 10.236.206.8 with SMTP id k8mr13090498yho.23.1419139096490; Sat, 20 Dec 2014 21:18:16 -0800 (PST) Original-Received: from floss.red-bean.com (64-145-114-106.client.dsl.net. [64.145.114.106]) by mx.google.com with ESMTPSA id 28sm9218335yhw.17.2014.12.20.21.18.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Dec 2014 21:18:15 -0800 (PST) In-Reply-To: <87k31mdbhe.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sat, 20 Dec 2014 16:30:37 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c07::235 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:180414 Archived-At: "Stephen J. Turnbull" writes: >Eric is stirring up nothing but trouble with his intemperate >vituperations. Karl is a little more circumspect, but he is also >going to fail. Of all free software philosophers, even more so than >RMS, *those two* should be well aware of the distinction between the >*software* and the *project*. A work of free software is the world's, >'tis true, but nary a project be that be not "owned" by its >participants. > >The right way to stir things up is to appeal to the choir, not to the >tourists gawking at the icons in the back of the hall. The criterion >for appeal of a new documentation format is clear: present a proof of >concept translation of a "representative" Emacs manual[1] to the new >source format, along with built manuals in the target format(s) and >any tools needed to implement the desired navigation features. The >cost is high, but experience shows that worthwhile moves usually have >redundant costs being paid. > >For example, I've observed 6 VCS transitions closely. In 3 cases >(including the current move of Emacs to git), the choice was based on >consensus of the involved developers, and only one conversion was done >(but note that Eric's conversion was not based on one of the existing >git mirrors, and was done a couple dozen times I guess). In the other >3 cases, multiple repos were presented for consideration -- a lot of >redundant effort from one point of view. > >In other cases (3 cases of issue tracker introduction), it was >universally agreed that "some" was better than "none". In two cases, >projects just took the first thing that had a volunteer to implement >and run the tracker. In the case of Emacs, however, there was a >strong demand that the existing email-centric workflow be extended, >and the only candidate with a proof-of-concept implementation that >satisfied that requirement was the current debbugs tracker. That >despite protests that Bugzilla, Roundup, Trac, etc "can be" configured >to be controlled by email. But no implementation was presented, and >debbugs won by default. > >I suspect a careful study would substantiate such anecdotes. For the >documentation format, the core members of the project clearly consider >the existing Texinfo manuals to be adequate (and often, excellent). >So there's no hurry to produce a proof of concept -- but I would say >one is necessary, and the cost is not exorbitant according to common >practice. Spot on, IMHO. Another way to look at it: Sometimes one can get a consensus that a transition would probably be a good idea, *in advance* of anyone doing the sample transition work. That advance consensus can then help motivate people to work on the change, because they have confidence that their work will eventually be used for the real transition. E.g., if there were broad consensus that a Web-based bug tracker (with APIs and email controllability) would *probably* be a good thing to move to from Debbugs, then someone might be more willing to work on it. What a critical mass of Emacs developers currently express is a slightly different stance, though: "Debbugs is good enough until someone comes along and shows a concrete implementation of something else that is unequivocally better." So now if someone's going to do all that work to demonstrate a different system, they're doing it under a much greater risk that their work will end up being wasted. The lever can be on one of two settings: "We stay here until something clearly better is shown" vs "We'd probably like to change, unless we unexpectedly discover that there's nowhere better to go." For many parts of the Emacs project, the lever is in the former position. I believe that in other projects the lever is in the latter position rather more often (than it is in Emacs), and consequent ly people are more motivated to work on those things -- because they feel there is less chance their work will be rejected in the end. Stephen, FWIW I don't think I was displaying any confusion between the software and the project (as per your first paragraph) :-). I'm quite aware of what it would take here, and merely regret that I don't, alas, have time right now to work on these things in a way that would be effective for the Emacs project. Best, -K