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: [ANN] New library stream.el in ELPA Date: Mon, 19 Oct 2015 13:38:05 +0900 Message-ID: <22052.29613.785079.277399@turnbull.sk.tsukuba.ac.jp> References: <87d1whk75h.fsf@petton.fr> <87si5djubt.fsf@petton.fr> <87pp0hjlhj.fsf@petton.fr> <5623E527.2090509@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1445229512 31763 80.91.229.3 (19 Oct 2015 04:38:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2015 04:38:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 19 06:38:28 2015 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 1Zo2DL-0006I2-No for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 06:38:27 +0200 Original-Received: from localhost ([::1]:36428 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo2DK-0007Sw-VD for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2015 00:38:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo2D7-0007Sq-J4 for emacs-devel@gnu.org; Mon, 19 Oct 2015 00:38:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zo2D2-00032t-IE for emacs-devel@gnu.org; Mon, 19 Oct 2015 00:38:13 -0400 Original-Received: from turnbull.sk.tsukuba.ac.jp ([130.158.96.25]:56184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zo2D2-00032o-1e for emacs-devel@gnu.org; Mon, 19 Oct 2015 00:38:08 -0400 Original-Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.86) (envelope-from ) id 1Zo2Cz-00038l-QS; Mon, 19 Oct 2015 13:38:05 +0900 In-Reply-To: <5623E527.2090509@dancol.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta34) "kale" 698a9aa86de4 XEmacs Lucid (x86_64-apple-darwin14.5.0) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: steve@turnbull.sk.tsukuba.ac.jp X-SA-Exim-Scanned: No (on turnbull.sk.tsukuba.ac.jp); SAEximRunCond expanded to false X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 130.158.96.25 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:192028 Archived-At: Daniel Colascione writes: > I prefer keeping code in master. Hackers always do. The vast majority of users aren't hackers, though. The vast majority of that vast majority (the half-vast majority?) loves community package repositories, and for good reason. N.B. I have no opinion on stream.el itself. My opinion is that these stdlib/package repo issues need to be decided case by case, and that in general a bias toward putting stuff in ELPA is not a bad thing. A bias toward putting everything in core should be avoided in the current state of the art. > That way, it's easily maintained and distributed automatically. Assuming it's maintained at all, and FVO "distributed" == "to the hackers who pull from master daily", yes. To industrial users who get their core Emacs from Debian or Red Hat, not so. > There's very little downside: nobody is going to miss a few tens of > kilobytes of compiled elisp. True but irrelevant, even when the specious "few kilobytes" (due to one small module) is replaced by the more realistic "many megabytes" (due to a plethora of small modules and a few monster packages). There is a lot of experience with standard libraries nowadays. A short list of the real tradeoffs involves: 1. Obsolescence/bitrot of stdlib code. 2. Maintainer effort to prevent/remediate (1). 3. Users who need to keep a few modules up to date, but prefer to get their core Emacs + from an OS distro. 4. Developers who always have a current build of master to hand, and can easily rollback using the VCS if that breaks, vs. (3). 5. Paranoid enterprise environments where ordinary programmers have to choose software from a list approved by HQ, and there's no blanket approval for the package repository. (Such users' best hope for access to new features is a short release cycle that fits the convenience of the enterprise's software audit team.) This is really the killer application for "everything in core", but I haven't heard this claim in Emacs channels (and the data I've seen on distribution of versions in a couple of large enterprises suggests that a large majority of industrial users are perfectly happy with 5-year-old Emacsen, and a significant minority often uses 10-year-old Emacsen). 6. Variations in development cycles between core and modules, and among modules. Similarity in cycles argues for joint release and distribution. 7. Discoverability of modules in the stdlib is probably higher, although as we've seen in several threads recently, even those with great interest in the subject can be sadly underinformed about the elephant in the room (eg CEDET/EDE). > I see no need to flake off useful parts of Emacs and put them into ELPA > when the core is not resource-constrained. You haven't noticed that there just aren't enough developers to fix all the bugs yet, let alone develop all of the attractive proposals? That there's only one volunteer for lead maintainer, and he's politically nonaligned in a flagship product of a political organization (not to mention having reservations about top management policy)?[1] 8. Of course to some extent those resource constraints argue for putting everything in core for the convenience of those who *do* do a lot of maintenance work on core. > For me, using ELPA packages is a bit more awkward, Emacs is not just about you and other core developers whose practices are basically similar to yours, though. > since I don't use package.el and pull in the bits of ELPA I want > manually. If your package is only in ELPA, I probably won't hear > about it, and unless it's particularly compelling, I won't use it. You may be more diligent, but Emacs (like other sprawling language and framework projects I know of) is such a mess[2] that most hackers won't use core code if they have to look for it. It's easier to build your own, submit/commit, and let Stefan et al. tell you there's a standard way that also has benefits X, Y, and Z for your application. 9. This is often a good thing, as the existing code may have limitations or even be quite inappropriate for the application to hand. Such experimentation is encouraged by package repos. I could go on, but I'll stop at 9, according to Guido's Rule of Single Digits. Footnotes: [1] I expect these issues to be resolved satisfactorily to all parties. But I wonder if John would have stepped forward if someone who is an enthusiastic advocate of the GNU approach to software freedom had their hat in the ring? [2] Organization of modules is worse than NP-hard. I have found a wonderful proof of this theorem but unfortunately it won't fit in a 4-line .sig.