emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea for determining what users use


From: Kim F. Storm
Subject: Re: Idea for determining what users use
Date: 04 Jun 2003 00:55:52 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Richard Stallman <address@hidden> 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 <address@hidden> http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]