From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Have you all gone crazy? Was: On being web-friendly and why info must die Date: Sun, 21 Dec 2014 15:37:22 +0900 Message-ID: <87mw6hse3h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87388bnzha.fsf@newcastle.ac.uk> <87k31mdbhe.fsf@uwakimon.sk.tsukuba.ac.jp> <87zjah7f8p.fsf@floss.red-bean.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1419143880 7362 80.91.229.3 (21 Dec 2014 06:38:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Dec 2014 06:38:00 +0000 (UTC) Cc: Phillip Lord , "Allen S. Rout" , emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 21 07:37:53 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 1Y2a9H-0006SH-2R for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2014 07:37:51 +0100 Original-Received: from localhost ([::1]:36609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2a9G-0002gq-4C for ged-emacs-devel@m.gmane.org; Sun, 21 Dec 2014 01:37:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2a8x-0002fk-Vd for emacs-devel@gnu.org; Sun, 21 Dec 2014 01:37:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2a8s-0001CW-1M for emacs-devel@gnu.org; Sun, 21 Dec 2014 01:37:31 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:51595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2a8r-0001BZ-GT for emacs-devel@gnu.org; Sun, 21 Dec 2014 01:37:25 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 307911C38C6; Sun, 21 Dec 2014 15:37:22 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 16BB11A2CFC; Sun, 21 Dec 2014 15:37:22 +0900 (JST) In-Reply-To: <87zjah7f8p.fsf@floss.red-bean.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:180416 Archived-At: Karl Fogel writes: > "Stephen J. Turnbull" writes: > >I suspect a careful study would substantiate [the] anecdotes > >[presented in an earlier post]. For the documentation format, the > >core members of the project clearly consider the existing Texinfo > >manuals to be a dequate (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. "Can", yes. Does, I dunno. The high-quality large contributions I know in some detail were mostly done "speculatively", because there was a need in the software -- not because there was demand from the project.[1] If you want control over integration, you typically need to either become trusted core, or you need to fork. Especially in Emacs. Little has changed here since the 1980s in that respect. > 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. That's a poor example, IMO. There's clearly no consensus, and there won't be one because the core really does prefer the email-based workflow. No? As I see it, anyway, here there's only one choice: build the damn mousetrap, and *show* the core that it catches mice without bruising their fingernails. If *you* don't have faith the mousetrap will be enough better, then it probably isn't enough better. > 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. I'm with Fred Brooks: build one to throw away. "You will, anyway." Cf. Eric -- he didn't throw just one repo away, he junked one every couple days for a few weeks. > I believe that in other projects the lever is in the latter > position rather more often (than it is in Emacs), and consequently > people are more motivated to work on those things -- because they > feel there is less chance their work will be rejected in the end. But there's a good reason for that: few projects are as old as Emacs, few works are of the quality of Emacs. *Many* of the projects are brand new; anything is better than nothing. (That's not entirely true; one of my GSoC projects was mandated by the org to use Podio for workflow. Nothing is *definitely* better than vanilla Podio. But I digress.) Very few are as solid, or have as well-established traditions and workflows, as does Emacs. Python is very similar to Emacs in terms of age and solidity, and there is a lunatic fringe there advocating random changes.[2] But real progress on anything like workflow changes in Python takes at least as much time as in Emacs, multiple Python Enhancement Proposals, often discussion at one, sometimes two of the annual Language Summits, and often multiple demonstration implementations. But (aside from the aforementioned fringe) nobody there thinks this process unnatural. > 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. I concede that you know your mind better than I do. But given that you *did* "write the book", I at least have trouble distinguishing your "I wish"es from your "You should"s. If you see what I mean. :-) Anyway, I apologize and will work on my own temper in the New Year. Happy Holidays to you and all the denizens of emacs-devel! Footnotes: [1] "In the software" is not a great expression -- as I see it, this applies to infrastructure projects too (especially things like repo mirrors in a different VCS, but including trackers and testing infrastructure), but the wording is poor for that. Even the tracker to some extent, although that (and mailing lists) are pretty much the most un-decentralizable aspects. [2] I don't consider any of the people currently advocating radical changes for Emacs to be lunatics at all. The culture is very different from Python.