From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: CVS is the `released version' Date: Fri, 25 May 2007 17:13:47 -0400 Message-ID: <2cd46e7f0705251413y975af0bwbd7c6709814fd915@mail.gmail.com> References: <86646mjvxp.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1180127640 6368 80.91.229.12 (25 May 2007 21:14:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 May 2007 21:14:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: "JD Smith" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 25 23:13:57 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hrh6i-0001GN-Cn for ged-emacs-devel@m.gmane.org; Fri, 25 May 2007 23:13:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hrh6h-0007DU-Ld for ged-emacs-devel@m.gmane.org; Fri, 25 May 2007 17:13:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hrh6d-0007Ck-4T for emacs-devel@gnu.org; Fri, 25 May 2007 17:13:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hrh6c-0007CY-IR for emacs-devel@gnu.org; Fri, 25 May 2007 17:13:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hrh6c-0007CV-Cg for emacs-devel@gnu.org; Fri, 25 May 2007 17:13:50 -0400 Original-Received: from an-out-0708.google.com ([209.85.132.241]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hrh6b-0000uT-Nh for emacs-devel@gnu.org; Fri, 25 May 2007 17:13:50 -0400 Original-Received: by an-out-0708.google.com with SMTP id c25so256681ana for ; Fri, 25 May 2007 14:13:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LveTAxw1g93iDAzMM2w7vV9J82RoUSMwXbmm2uXYrUIcb89cnaN7lZXuMi6ysAoArtEk4h10hvJrhiIAncZDaB8gKW00q79ziKzolZgf9/gwWurnCtI18Ux+BgcJizFORSj+d7uIh4zqOSocYyYkg4sUl2heAonYo16rSXO2c60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zg4Ba0nttHymQ2QmA7S2Ol8pfwFTW28eSjC4WiI3HJ661YZL3acnSlzcVY8EcGZBIpWqirR/bOj0wXjdYkV5/+r2MZkNPPky/rzjOxWz5yn3022jGGPgQl5fIbHr8nn/eNFwKlHf+DluILoLjhn2wrZ/ueLAuU9RBtveRdmiPGM= Original-Received: by 10.100.225.13 with SMTP id x13mr3044838ang.1180127627727; Fri, 25 May 2007 14:13:47 -0700 (PDT) Original-Received: by 10.100.9.13 with HTTP; Fri, 25 May 2007 14:13:47 -0700 (PDT) In-Reply-To: Content-Disposition: inline X-detected-kernel: Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:71813 Archived-At: On 5/21/07, JD Smith wrote: > At the very minimum, an integrated, easy to use capability to update > assigned, core Emacs packages between releases would be very welcome. i agree - i think this issue is very important. from people's responses in this thread, it's apparent that it's complicated by a few concerns. i think the discussion is getting muddied by intermixing of the concerns, and it would be helpful to explicity distinguish and address them. my take: (1) we are talking about enabling package developers and users to update the packages they use incrementally within a major emacs release, (2) without burdening emacs maintainers with change management chaos, and (3) without reducing the incentive for package developers to assign copyright to the fsf. (1) is the purpose of the thing, and seems quite valuable to me. it would reduce the pressure for emacs major releases, or conversely, reduce the impedence that delays in an emacs major release presents. those of us that feel confident about the general polish of the CVS head, and our ability to tackle problems when they creep in, have a version of this by using an emacs checked out and built form the head. we get bug fixes quickly, and get to enjoy valuable features and improvements as they arrive. (3) copyright assignment incentives could be maintained by requiring copyright assignment for inclusion of a package in the system. this may be severe, however - perhaps it would be enough to require assignment for inclusion in the default collection, but enable inclusion of alternate collections? i think this is the gist of one of the discussions that tom tromey and richard are having in this thread. whatever the choice, it seems like this can be kept as close to the status quo as desired, and relaxed as much as willing, by choice. (2) is the tricky bit. the situation would be simplest if the update system is contrived to only allow the entire collection of packages to be updated at as a whole. this would mean that package committers need worry only about interoperation with the current version of other packages, not with the diversity available. ("current" would be a gradually moving target, but at least there would be only one target at any moment.) what this would amount to is a finer incremental release mechanism for the lisp directory, as a whole. this would be very like someone following emacs development via the CVS head, with the addition that the releases could be better controlled to ensure coherence/integrity, rather than being wherever checkins happen to be. the cygwin installer for the cygwin gnu/linux distribution presents an example of another, more intricate mode, which i like. (gentoo's portage and debian's apt systems are (much) more elaborate versions of this mode, the cygwin version has the advantage of a compact, concise interface.) in it, collections of package versions are offered together, and the user has to specifically elect for exceptions from the standard (or alternate) version collections. by deliberately choosing the exceptions, the user is aware that they're departing from the programmed situation. we could even have bug reporting mechanisms note such departures, to at least have the deviance reported. the question here is how much turbulence would be introduced by allowing more frequent incremental release of the packages, and further, more intricate combinations of package versions. i think both are worth considering. -- ken http://myriadicity.net