From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Adding packages to ELPA Date: Fri, 19 Sep 2014 14:13:34 -0400 Message-ID: References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <877g11c8wh.fsf@gmx.us> <83fvfo15z7.fsf@gnu.org> <8361gj20h7.fsf@gnu.org> <83zjdvzmd5.fsf@gnu.org> <83tx43zfep.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411150455 6141 80.91.229.3 (19 Sep 2014 18:14:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2014 18:14:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 19 20:14:07 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 1XV2h4-0007s4-3D for ged-emacs-devel@m.gmane.org; Fri, 19 Sep 2014 20:14:06 +0200 Original-Received: from localhost ([::1]:59853 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XV2h3-0003UP-EB for ged-emacs-devel@m.gmane.org; Fri, 19 Sep 2014 14:14:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XV2gu-0003TG-Fs for emacs-devel@gnu.org; Fri, 19 Sep 2014 14:14:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XV2gn-0003cP-0L for emacs-devel@gnu.org; Fri, 19 Sep 2014 14:13:56 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XV2gf-0003ay-4V; Fri, 19 Sep 2014 14:13:41 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSQth1cI0hkXji0ESQeEOASpGYFqg0whgS0 X-IPAS-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSQth1cI0hkXji0ESQeEOASpGYFqg0whgS0 X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="90308585" Original-Received: from 69-165-145-6.dsl.teksavvy.com (HELO pastel.home) ([69.165.145.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Sep 2014 14:13:34 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 7B2FB642C6; Fri, 19 Sep 2014 14:13:34 -0400 (EDT) In-Reply-To: <83tx43zfep.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 Sep 2014 20:30:38 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:174573 Archived-At: >> >> - GNU ELPA packages can be released on their own schedule. >> > Same is true if they are in the Emacs repository. >> Not really. There are always interferences one way or the other between >> Emacs's release cycle and the packages's own release cycles. > No, I mean that a package that is part of Emacs can be used to create > a separate tarball disregarding the rest of Emacs. After all, once > you checkout the repo, they are just file in a certain directory. But if you want to make release 3.4 with some new changes, you first need to commit those changes, and if the trunk is frozen you can't do this commit so easily. Can it be done, yes. But having the package be completely separate makes things a lot easier. Another aspect of GNU ELPA is that people get to discover the new packages as they get added (if they check the ELPA archive regularly, or if they read gnu.emacs.sources), as opposed to having them smashed together, drowned in the large list of changes in etc/NEWS. > Maybe you are right, but we will not know that unless we try. I bet > your feeling of being stretched thin is not based on facts, just on > gut feelings. I'm not really sure about that. I know *I*'m stretched really thin. >> Indeed, and that is also a problem. For that reason, more of the newer >> packages are added as branches rather than as directories in the main >> branch. This mean you don't need the whole repository to hack on them. > I have 1.5TB of disk storage on my main development machine. I refuse > to believe that these small figures make a difference to someone these > days. Nowadays it's very common to never use "just the source" but "the source with its VCS metadata". Everywhere. So if your config uses package Foo, you'll want to have that package's VCS metadata in your config. That gets copied to every one of your various accounts. Some of those accounts may have significant quota constraints, or be on rather smallish rented virtual machines, or on a small home router with no HDD. Can those cases accommodate 300MB of extra stuff? Possibly, but you may have to choose between that and something else. Also, if you have N such packages. Are you going to use up 300MB * N of disk space? That can become more problematical, so you'll have to go through extra hoops to try and share that redundant data, which you wouldn't need to do if they were separate to start with. And of course in some situations, the bandwidth requirement, or the processing requirements (it takes much longer to go through that 300MB of metadata) is more problematical than the disk space itself. But the argument is the same. Stefan