From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Idea for determining what users use Date: 04 Jun 2003 00:55:52 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5xof1ebwjr.fsf@kfs2.cua.dk> References: <59EC6788-92AE-11D7-8588-00039363E640@swipnet.se> <200306010124.h511OFZ22272@eel.dms.auburn.edu> <200306010159.h511xiE22326@eel.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1054674161 32305 80.91.224.249 (3 Jun 2003 21:02:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 3 Jun 2003 21:02:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 03 23:02:37 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19NIvV-0008Of-00 for ; Tue, 03 Jun 2003 23:02:37 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19NJCm-0001ZD-00 for ; Tue, 03 Jun 2003 23:20:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NIuV-0000Ab-Ry for emacs-devel@quimby.gnus.org; Tue, 03 Jun 2003 17:01:35 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19NIsn-000862-13 for emacs-devel@gnu.org; Tue, 03 Jun 2003 16:59:49 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19NIrH-0006GH-4c for emacs-devel@gnu.org; Tue, 03 Jun 2003 16:58:16 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19NIqi-0005tn-BZ; Tue, 03 Jun 2003 16:57:40 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 552E07C012; Tue, 3 Jun 2003 22:57:38 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: Original-Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-cc: jan.h.d@swipnet.se Original-cc: monnier+misc/ads@rum.cs.yale.edu Original-cc: monnier+gnu/emacs@rum.cs.yale.edu Original-cc: Luc Teirlinck Original-cc: alex@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14658 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14658 Richard Stallman writes: > Also it seems that a user who wants the mail buffer can always get it > using M-x report-emacs-bug or using the menu. > > A user who decides "I want to tell the Emacs developers something" > might do this. The idea of my proposal is to get people to send us > mail about issues which they did not know about. I still think we are wasting our time on this issue. IMHO there is a much simpler solution: - If we think a package has been superseded by something better, we move the package to lisp/obsolete/ - We describe this very clearly in NEWS by creating a new section: * Obsoleted features in 21.5 This will describe what packages are obsoleted, what the user should do to stop using the obsolete feature, and what alternative solutions we recommend instead. - If a user uses the obsolete feature, he gets a warning in his *Messages* buffer telling him there is a better alternative (could refer the user to NEWS for more info). - The user may overlook or disregard this warning ... and continue to use the obsolete feature, probably for several emacs releases to come. - We simply keep the obsolete feature in future releases of emacs, unless the feature is too difficult to maintain. - If a user really cares about using the obsolete package, he is welcome to report a bug about it, and tell us clearly why he thinks obsoleting the old package is wrong. So Richard, please answer these questions: 1) What additional benefits do we get from "annoying" users with the proposed "usage polls", compared to the simple scheme above? 2) How many users should report to be using a feature for us to move it out of obsolete again? Less than five? (In that case, I would argue that having the package in obsolete could indeed the right place for it!) 3) If we have moved a package to obsolete because we have something better, how do you interpret what the usage polls tells us? In most cases, the right choice for the user is simply to switch to the new package (he probably just wasn't aware of the new package, or has been too lazy to switch). Only in rare cases, the user continues to use the obsolete package because it provides some feature that isn't provided by the new package -- any with your 1-bit polls, you won't really know what that specific feature is -- so we cannot fix the new package. In any case, I think that we need to make this a user option, so it can be easily turned off. (I would expect the various GNU/Linux distributions would do this, independent of whether we enable it by default). -- Kim F. Storm http://www.cua.dk