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: package and testing rant (was Re: package.el, auto-installation, and auto-removal) Date: Thu, 13 Nov 2014 10:09:20 +0900 Message-ID: <87ioijx5xb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87a943umku.fsf@lifelogs.com> <87ppcvm7fj.fsf@newcastle.ac.uk> <87vbmndk46.fsf@lifelogs.com> <87wq72ls2h.fsf@ferrier.me.uk> <87k332lnn3.fsf_-_@ferrier.me.uk> <878ujhtx89.fsf@Rainer.invalid> <8761eki9ym.fsf@ferrier.me.uk> <87sihogkt0.fsf@ferrier.me.uk> <87bnocgh1r.fsf@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1415841000 4908 80.91.229.3 (13 Nov 2014 01:10:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Nov 2014 01:10:00 +0000 (UTC) Cc: Achim Gratz , Stefan Monnier , emacs-devel@gnu.org To: Nic Ferrier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 13 02:09: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 1Xoiv1-0003KL-Bs for ged-emacs-devel@m.gmane.org; Thu, 13 Nov 2014 02:09:51 +0100 Original-Received: from localhost ([::1]:57375 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoiv0-0004wz-S8 for ged-emacs-devel@m.gmane.org; Wed, 12 Nov 2014 20:09:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xoiuh-0004wp-OS for emacs-devel@gnu.org; Wed, 12 Nov 2014 20:09:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xoiua-00023P-7X for emacs-devel@gnu.org; Wed, 12 Nov 2014 20:09:31 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:58499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoiuZ-00021u-N8 for emacs-devel@gnu.org; Wed, 12 Nov 2014 20:09:24 -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 463E71C3A71; Thu, 13 Nov 2014 10:09:20 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2BB741A2844; Thu, 13 Nov 2014 10:09:20 +0900 (JST) In-Reply-To: <87bnocgh1r.fsf@ferrier.me.uk> 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:176866 Archived-At: Nic Ferrier writes: > A GNU project is a GNU project, is my understanding. savannah can host > non-gnu or GNU. GNU projects all need (C) assignment. You can't be GNU > without that. No, GNU has never tried to monopolize copyright. A few "strategic" projects do require assignment or equivalent (mostly those RMS was directly involved with creating, such as Emacs, of course, and GCC), and it's recommended for all projects based on experience with license migrations. But it's a project by project decision, and always has been. > I don't see why it's any more easy to get bugs fixed. If a > maintainer for a GNU project disappears there's a regular course of > action to chase them up or hand off control. Isn't there? There > used to be. Sure, but somebody has recognize that the maintainer has gone AWOL and then go do the chasing. This way the bugs reports are shared, to some extent channels are shared, and it's relatively easy to recognize when a maintainer has become unresponsive. Consider the (lack of) success of the "regular course of action" vis-a-vis Bazaar. Somebody raised his hand, became the official maintainer of GNU Bazaar, and has never been heard of again. The people who have explicitly disclaimed responsibility for that project have been far more active! > > That depends on what you compare it with. You're comparing it to having > > your package on some random Git server somewhere, but if you compare it > > to having your package in Emacs itself, then it's much more "your" > > source tree, and it has fewer constraints. > > But my comparison is what most authors will experience. So? GNU ELPA is part of Emacs, it's not a collection of random packages. > Unless you're going to only talk to authors who already contribute to > gnu emacs. s/already/want to/ and you have it! > I mean that people who want to have an odd build will attempt to make > the Makefile do it and then break it. I don't see a difference. > >> You're also inviting people to check in non-working code. Again, I don't see a difference. Between Emacs core and "some random Git server somewhere", yes. Not between ELPA and a separate git project. People who check in non-working code in random projects in a common repository can be slapped hard (I've removed commit privileges after two warnings to revert, Stefan might or might not be more polite :-). Ask Micheal Albinus or Alan Mackenzie how often random people have broken TRAMP or CC-mode in the XEmacs package repo. It just doesn't need to happen, because core and the ELPA projects are different. The people who maintain Emacs core are grownups, they don't think that because they're "core" that gives them rights to mess with projects they're only loosely associated with. > > I'd accept patches to the GNU ELPA scripts which lets authors do that. > > Note that I've heard comments from other authors who find the "just bump > > the version number" way of making a release to be really handy, so > > I wouldn't want to force people to make their own archive. > > Really handy vs safe is something I think should err on the side of > safe. "Bump the version number" has worked for XEmacs for a decade. I don't recall any packaging bugs of the "somebody broke make bootstrap, just needs a trivial patch" level. > >> I mean: You're doing something very weird. Why? > > > > I guess I just don't know what's weird about it. > > Maybe you don't know enough about software ecosystems? Maybe you don't know enough about Emacs and GNU? :-) Specifically, the term "software ecosystem" is deprecated here. You'd have to read the FSF FAQ or ask RMS for the party line, but my take on it is that the FSF and GNU have taken the role of guardian (legal and developer, repectively) of software freedom, and decisions are taken explicitly about project and Project organization as well as specific development practices, and even features, in the interest of free software. Decisions in these matters are not based on "natural ecological" relationships among participants. Note well: In practice, although I'd quibble about details, I prefer to run things basically in the way you suggest. But that is not the way things are done in Emacs or in the free software movement (vs. open source community) in general. Regards,