From: storm@cua.dk (Kim F. Storm)
Cc: ttn@glug.org, rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Possible change to startup.el
Date: Fri, 01 Apr 2005 00:19:25 +0200 [thread overview]
Message-ID: <m3acoj1ms2.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <x5k6noj5gk.fsf@lola.goethe.zz> (David Kastrup's message of "Thu, 31 Mar 2005 15:43:55 +0200")
David Kastrup <dak@gnu.org> writes:
>> Is this really a _very important improvement_?
>>
>> Why is this _more important_ than reporting sensible menu bindings?
>
> It was a reaction due to actual user feedback about a perceived
> shortcoming, so its relative importance _could_ be argued.
I never intended to start making comparisons of relative importance of
each and every suggested change -- but RMS says we shall focus on
fixing bugs and that he will only accept "very important improvements"
before the release. That's fine, and I really doubt that _any_
improvement at this time can be considered "very important".
So based on that I can understand why minor improvement A was rejected
last week, but then I don't understand why minor improvement B is
accepted this week. What improvements will be accepted next week?
> Kim, I am obviously supportive of your patch for the sake of our
> users [...] and I don't agree with (actually find it hard
> to understand) Richard's assessment of its irrelevancy.
I obviously agree :-) but still I can accept the rejection (at this
time) based on the argument that it is not a "very important
improvement" for 22.x.
But then I would expect a similar rejection of other suggestions
that are not "very important improvements".
> But a
> perceived shortcoming in one issue should not be used for blocking
> progress in other areas.
IMO, the only acceptable "progress area" at this time is "completing
the release". Any other kind of "progress" should be rejected.
> If one has
> a strong opinion about something, it is hard to accept that others may
> see it as mostly irrelevant.
Yes, I can accept objective reasons for a rejection -- a subjective
rejection based on "irrelevance" is harder to accept :-)
> We are all trying to make Emacs the best that is possible, after all.
Sadly, making "the best that is possible" often seems to take focus
away from "finalizing the release" based on what we already have which
IMO is "good enough"... (I'm no better than others in that respect :-)
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2005-03-31 22:19 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-31 12:01 Possible change to startup.el Thien-Thi Nguyen
2005-03-31 12:59 ` Kim F. Storm
2005-03-31 13:43 ` David Kastrup
2005-03-31 22:19 ` Kim F. Storm [this message]
2005-04-01 4:10 ` Richard Stallman
2005-04-01 4:03 ` Juri Linkov
2005-04-03 5:20 ` Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2005-04-03 10:31 Thien-Thi Nguyen
2005-04-07 6:55 ` Juri Linkov
2005-04-08 3:22 ` Richard Stallman
2005-04-08 6:31 ` Marcelo Toledo
2005-04-08 7:27 ` Kenichi Handa
2005-04-08 18:32 ` Juri Linkov
2005-04-08 18:43 ` Marcelo Toledo
2005-04-10 1:54 ` Richard Stallman
2005-04-08 10:44 ` Eli Zaretskii
2005-04-08 18:32 ` Juri Linkov
2005-04-09 8:00 ` Eli Zaretskii
2005-04-13 23:58 ` David Kastrup
2005-04-14 4:02 ` Eli Zaretskii
2005-04-14 9:46 ` David Kastrup
2005-04-15 8:15 ` Eli Zaretskii
2005-04-14 19:03 ` Richard Stallman
2005-04-14 23:40 ` David Kastrup
2005-04-17 1:49 ` Richard Stallman
2005-04-17 9:31 ` David Kastrup
2005-04-17 19:20 ` Richard Stallman
2005-04-17 19:51 ` David Kastrup
2005-04-10 1:54 ` Richard Stallman
2005-03-31 11:37 Thien-Thi Nguyen
2005-03-31 12:05 ` Miles Bader
2005-03-31 13:32 ` Thien-Thi Nguyen
2005-03-31 14:29 ` Miles Bader
2005-03-31 16:15 ` Thien-Thi Nguyen
2005-03-31 22:23 ` Miles Bader
2005-04-01 4:10 ` Richard Stallman
2005-03-30 22:47 Thien-Thi Nguyen
2005-03-30 23:38 ` David Kastrup
2005-04-01 4:11 ` Richard Stallman
2005-03-31 1:40 ` Miles Bader
2005-03-31 1:02 ` Marcelo Toledo
2005-03-31 3:20 ` Miles Bader
2005-03-31 2:21 ` Marcelo Toledo
2005-03-31 6:59 ` Juri Linkov
2005-04-01 4:11 ` Richard Stallman
2005-03-25 18:07 Thien-Thi Nguyen
2005-03-27 3:52 ` Richard Stallman
2005-03-27 23:15 ` Juri Linkov
2005-03-28 22:53 ` Richard Stallman
2005-03-29 20:19 ` Thien-Thi Nguyen
2005-03-30 4:08 ` Marcelo Toledo
2005-03-30 9:42 ` Thien-Thi Nguyen
2005-03-24 10:49 Thien-Thi Nguyen
2005-03-24 19:05 ` Miles Bader
2005-03-25 6:43 ` Richard Stallman
2005-03-21 18:44 David Kastrup
2005-03-21 20:50 ` Thien-Thi Nguyen
2005-03-21 21:10 ` David Kastrup
2005-03-21 21:25 ` Andreas Schwab
2005-03-21 22:14 ` David Kastrup
2005-03-22 0:03 ` Andreas Schwab
2005-03-22 1:38 ` David Hansen
2005-03-23 18:25 ` James Cloos
2005-03-27 3:53 ` Richard Stallman
2005-03-22 4:55 ` Eli Zaretskii
2005-03-22 6:24 ` Miles Bader
2005-03-22 8:15 ` Kenichi Handa
2005-03-22 8:27 ` Miles Bader
2005-03-22 10:40 ` David Kastrup
2005-03-22 12:44 ` Jason Rumney
2005-03-22 20:31 ` Werner LEMBERG
2005-03-22 11:23 ` Kenichi Handa
2005-03-22 12:33 ` Juri Linkov
2005-03-22 19:32 ` Eli Zaretskii
2005-03-22 10:18 ` David Kastrup
2005-03-22 19:34 ` Eli Zaretskii
2005-03-22 22:24 ` David Kastrup
2005-03-22 20:44 ` Richard Stallman
2005-03-22 22:32 ` Thien-Thi Nguyen
2005-03-23 6:21 ` Richard Stallman
2005-03-23 13:55 ` Juri Linkov
2005-03-23 18:01 ` Werner LEMBERG
2005-03-25 12:51 ` Kenichi Handa
2005-03-23 20:25 ` Richard Stallman
2005-03-22 13:57 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3acoj1ms2.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
--cc=ttn@glug.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.