From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Should Emacs have an upgrade procedure? Date: Sun, 21 Mar 2010 21:36:36 +0100 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269203824 27969 80.91.229.12 (21 Mar 2010 20:37:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 21 Mar 2010 20:37:04 +0000 (UTC) Cc: 'Emacs development discussions' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 21 21:36:53 2010 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.69) (envelope-from ) id 1NtRtE-0002Ae-OO for ged-emacs-devel@m.gmane.org; Sun, 21 Mar 2010 21:36:53 +0100 Original-Received: from localhost ([127.0.0.1]:60331 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtRtE-0005PK-0P for ged-emacs-devel@m.gmane.org; Sun, 21 Mar 2010 16:36:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtRt8-0005P4-US for emacs-devel@gnu.org; Sun, 21 Mar 2010 16:36:46 -0400 Original-Received: from [140.186.70.92] (port=34662 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtRt6-0005Oj-Ry for emacs-devel@gnu.org; Sun, 21 Mar 2010 16:36:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NtRt3-0005Pe-2P for emacs-devel@gnu.org; Sun, 21 Mar 2010 16:36:44 -0400 Original-Received: from iwfs.imcode.com ([82.115.149.64]:39780 helo=gate.verona.se) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NtRt2-0005PV-KY for emacs-devel@gnu.org; Sun, 21 Mar 2010 16:36:41 -0400 Original-Received: from localhost.localdomain (IDENT:1005@localhost [127.0.0.1]) by gate.verona.se (8.13.4/8.11.4) with ESMTP id o2LKaaa8013774; Sun, 21 Mar 2010 21:36:37 +0100 In-Reply-To: (Drew Adams's message of "Sun, 21 Mar 2010 10:21:10 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 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:122418 Archived-At: "Drew Adams" writes: >> Should Emacs have an upgrade procedure? >> >> Here's a user story: >> - The user has just installed Emacs 24, previously having running >> Emacs23 >> - The Emacs splash screen shows a message: "A number of defaults have >> been changed between Emacs 23 and 24. Would you like to go >> through the changes, or just enable them?". This message is NOT >> shown if the user previously had expressed an opinion about >> these particular defaults. >> >> OK, you get the picture I suppose. Good or bad? There are elisp >> libraries out there that already implements this of course. > > Good or bad? Good. Good! > > That is, some additional, better way to do these two things would be welcome: I try to adress your concerns below from the perspective of the subject "Should Emacs have an upgrade procedure?". This doesnt mean I reject your thoughts. > 1. Let users know about such changes (including also new features, not just > changes in defaults). > > NEWS is what it is - necessary, probably, but not ideal as a user aid. An > additional way to present the change info would be welcome. NEWS is somewhat > implementation-centric or development-centric. A top-level user-centric view > would be a helpful addition. This isnt within the scope of the proposal. > 2. Let users make at least an initial decision about acceptance of such changes. > On a group basis and on an individual-change basis. This is handled well by an upgrade procedure I think. > > Dunno about particular ways to do #1 and #2 (including the scenario you > suggest), but I agree about the basic idea. In general terms, these would help, > IMO: > > 1. Some kind of tour of the changes and their impact for users. This is an > education thing, a means to give users an idea whether they might want to > accept/enable such-and-such change or not. This could be Web-based, esp. if > local resources are a problem. The "upgrade process" proposal doesnt try to cover this. > 2. Some kind of easy dialog to let them opt in/out for individual changes, and > for large groups of changes at once, and even for all changes. Yes. > #2 could be done using an organized dialog box (groups of check boxes, for > example). Or something else could be devised. (A "wizard-like" long sequence of > "Do you want X?" is a no-no, IMO.) I agree. > > 3. Each change demo'd or illustrated in #1 should be a choice in #2, and vice > versa. The choice dialog of #2 could even have individual links to the > corresponding illustrations in #1 - education is also about reminding. And vice > versa: in the tour presentation of a particular change, there could be a link to > the part of #2 that lets you choose. > > 4. It should be easy to (a) skip #2 altogether and (b) do #2 later, at any time > (including redoing it, changing one's mind). Obviously, it should also be easy > to skip #1. Users should not have to hunt later to find how to (re)do #1 and #2. > Two places we could provide quick links to #1 and #2: the Help menu and the > splash page. > > 5. It would be good for a user to be able to do #1 and #2 for past releases as > well. Rollback is within the scope of upgrade handling I think. > > This would require, at the least, having a way to identify internally each > user-visible change for a given release (or at least those deemed important > enough to figure in #1 and #2). Maybe this could be realized as flags to defcustom? > > Do I expect that this will really happen anytime soon, given our limited dev > resources (not to mention our difficulties to agree, especially about UI)? No. > But identifying and agreeing on the goal is one step, and some baby steps toward > realizing it could perhaps be accomplished. > > So yes, I think the question you raise is a good one, and your proposal is a > reasonable one to consider. > > (I wouldn't characterize this as being about an "upgrade procedure", however. > It's more about (a) educating users about changes and (b) facilitating their > control over those changes.) This particular thread was about finding out if a strictly scoped upgrade process could maybe help with solving, lets say, 80% of the concerns you rise. -- Joakim Verona