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: Stale undo-tree in elpa Date: Tue, 30 Dec 2014 11:40:38 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1419957658 18412 80.91.229.3 (30 Dec 2014 16:40:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Dec 2014 16:40:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Kelly Dean" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 30 17:40:52 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 1Y5zql-0006pu-Gw for ged-emacs-devel@m.gmane.org; Tue, 30 Dec 2014 17:40:51 +0100 Original-Received: from localhost ([::1]:37431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5zqk-0006CR-FC for ged-emacs-devel@m.gmane.org; Tue, 30 Dec 2014 11:40:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5zqg-0006CI-80 for emacs-devel@gnu.org; Tue, 30 Dec 2014 11:40:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5zqb-0006Cz-Dt for emacs-devel@gnu.org; Tue, 30 Dec 2014 11:40:46 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:10271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5zqb-0006Cv-9T for emacs-devel@gnu.org; Tue, 30 Dec 2014 11:40:41 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQPAOwQflRFpY0B/2dsb2JhbABbgwdSWYI1hVq+fIYhBAICgSQXAQEBAQEBfIQDAQEDAVYjBQsLNBIUGA0kiEoJ1lkBAQEBBgEBAQEekG8HhEgFiwGKHohNkUOBeIQZITCCRwEBAQ X-IPAS-Result: AnQPAOwQflRFpY0B/2dsb2JhbABbgwdSWYI1hVq+fIYhBAICgSQXAQEBAQEBfIQDAQEDAVYjBQsLNBIUGA0kiEoJ1lkBAQEBBgEBAQEekG8HhEgFiwGKHohNkUOBeIQZITCCRwEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="104168344" Original-Received: from 69-165-141-1.dsl.teksavvy.com (HELO ceviche.home) ([69.165.141.1]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Dec 2014 11:40:40 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 7DCF6660FB; Tue, 30 Dec 2014 11:40:38 -0500 (EST) In-Reply-To: (Kelly Dean's message of "Tue, 30 Dec 2014 10:01:48 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.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:180890 Archived-At: > It appears the FSF doesn't automatically pull, [ FWIW, the FSF doesn't have much to do with this, other than providing the hardware resources to host elpa.gnu.org, and holding the copyright for the code. ] No, indeed elpa.git is not auto-updated by pulling from some remote repository. Instead it's the package maintainer's responsibility to keep his elpa.git code uptodate. I did consider auto-pulling, but for now I decided it's better not to: it's better to have a human take responsibility for installing code into elpa.gnu.org. Note that pulling can't be made 100% automatic since there can be conflicts. > and instead either manually pulls or relies on package maintainers to > push, but people are busy with other things. An easy way to avoid those problems and save time is to use elpa.git as the upstream on which all work is done. That's the recommended way to use elpa.git. > For packages such as undo-tree that have only a trunk, not separate devel > and stable branches, the assumption must be that new versions are unstable > unless declared otherwise. Stability of the code is largely irrelevant since new packages are only created from elpa.git when the "Version:" header of the package is modified. Furthermore, releasing a broken package is not a big deal either since releasing a fix is quick&easy. Stefan