all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: emacs-devel@gnu.org
Subject: Can we give Eli a break, please?  [ Was: Re: Development Speed ]
Date: Wed, 22 Dec 2021 16:43:07 +0000	[thread overview]
Message-ID: <YcNVm26TFO/eR9dF@ACM> (raw)
In-Reply-To: <87k0fwy6wi.fsf@telefonica.net>

Hello, Óscar.

On Wed, Dec 22, 2021 at 16:51:41 +0100, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Wed, 22 Dec 2021 11:09:09 +0100

> >> The amount of tension and obstructionism that emerges every time that
> >> someone suggests implementing some technology less than 20 years old is
> >> overwhelming.

> > Generalizations are almost always risking losing accuracy, but this
> > one does that with a vengeance.  I think it's not only inaccurate
> > (when talking about Emacs development), but also simply unfair.  E.g.,
> > some of the recent developments in Emacs use technology that is much
> > newer than "20 years", and I challenge you to come up with examples
> > that could back up your generalization, or even come close.

Your last post comes over as one big moan.  You moan about perfectly
valid decisions, some of which didn't turn out optimally.  You moan about
perfectly valid decisions, full stop.  You or somebody else could have
moaned about the opposite decisions, had they been so taken, equally
well.

The main point of my post is that Eli is having to deal with a lot of
negative posting at the moment, and this is a Bad Thing.  He could do
with a break.

We're approaching what is in large swathes of the world the "season of
goodwill".  Why don't we reflect that in our posts to emacs-devel, in
particular to those directed at Eli?

I'm not going to respond to your points in detail; that would just lead
to more interminable arguments.  Suffice it to say that I disagree with
most of them as well as disliking the tone they were expressed in.

A happy Christmas to you!

> Example: the painful road from CVS to a modern VC system (first bzr and
> then Git when was clear that bzr was inadequate at several levels, as
> some warned before it was adopted.) And then many contributors didn't
> bother to adapt to the distributed workflow and keep using Git as if it
> were CVS, which makes the VC history hard to follow and of diminished
> value.

> Another example: the mailing list used as a bug tracker. We went from no
> tracker at all to a big hack that happens to accommodate the personal
> preferences of a few contributors while making things harder for
> everyone else. Basic things like subscribing to a bug are too advanced:
> you either monitor the mailing list or out of touch.

> Another example: the amount of old cruft and hacks that pervades the
> source code, prominently the C part.

> The motif port was re-enabled with the excuse of two users saying that
> they use it (two users! which actually didn't actually said that they
> use the port, just that they build it.)

> A the same time someone suggested experimenting with a new approach to
> display and he was shunned ("We tried with such a library, many eons
> ago. It was named lwlib, and you can judge for yourself how successful
> it is.") Right, because if it failed many eons ago, trying again is
> doomed to fail for sure, as technologies in software change as often as
> in medieval masonry; and what the OP was suggesting is not what lwlib
> does, IIUC.

> So we maintain old code because two people "complain" (they didn't) and
> meet with... let's say skepticism, proposals that seem to require
> significant changes on the source base but with a high impact on
> improving Emacs' potential. Lots of features and fixes are made trying
> to not change the "stable" code, that's why we end having functions over
> 1000 lines long sprinkled with #ifdefs, which not only make any
> substantial change very difficult, but are a big red sign saying "here
> be dragons."

> Emacs' architecture favors plug-in components, in the form of Elisp
> packages, external processes and C libraries exposed to Elisp. That's
> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
> But working on certain key parts of the core is very hard, both
> technically and socially. You are concerned about the lack of C
> contributors, but I think your worries are not well focused: there are
> still plenty of C hackers around, but do they see our C core as
> something they would enjoy contributing to?

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2021-12-22 16:43 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 10:52 Development Speed xenodasein--- via Emacs development discussions.
2021-12-21 11:05 ` Po Lu
2021-12-21 11:25   ` xenodasein--- via Emacs development discussions.
2021-12-21 11:37     ` Po Lu
2021-12-21 14:47       ` xenodasein--- via Emacs development discussions.
2021-12-22  0:56         ` Po Lu
2021-12-22  1:05           ` xenodasein--- via Emacs development discussions.
2021-12-21 12:05     ` Stefan Kangas
2021-12-21 12:20       ` Theodor Thornhill
2021-12-21 14:14       ` xenodasein--- via Emacs development discussions.
2021-12-21 14:48 ` Eli Zaretskii
2021-12-22  4:16 ` Richard Stallman
2021-12-22 10:09   ` Óscar Fuentes
2021-12-22 10:22     ` Po Lu
2021-12-22 10:38       ` Óscar Fuentes
2021-12-22 10:45         ` Po Lu
2021-12-22 13:47         ` Eli Zaretskii
2021-12-23  3:43         ` Richard Stallman
2021-12-23  9:50           ` Óscar Fuentes
2021-12-23 10:37             ` Po Lu
2021-12-23 10:52               ` Óscar Fuentes
2021-12-23 10:54               ` Arthur Miller
2021-12-24  4:13               ` Richard Stallman
2021-12-24  4:13             ` Richard Stallman
2021-12-22 14:21       ` Dmitry Gutov
2021-12-23  1:00         ` Po Lu
2021-12-23  1:05           ` Dmitry Gutov
2021-12-23  1:07             ` Po Lu
2021-12-23  2:18               ` dick
2021-12-23  6:39                 ` Eli Zaretskii
2021-12-23 10:46               ` Dmitry Gutov
2021-12-23 12:54                 ` Arthur Miller
2021-12-22 13:41     ` Eli Zaretskii
2021-12-22 15:51       ` Óscar Fuentes
2021-12-22 16:43         ` Alan Mackenzie [this message]
2021-12-22 17:07           ` Can we give Eli a break, please? [ Was: Re: Development Speed ] Óscar Fuentes
2021-12-22 17:12           ` dick
2021-12-22 17:43             ` Eli Zaretskii
2021-12-22 17:12         ` Development Speed Eli Zaretskii
2021-12-22 18:49           ` Óscar Fuentes
2021-12-23  3:43     ` Richard Stallman
2021-12-23 10:13       ` Óscar Fuentes
2021-12-23 10:35         ` Po Lu
2021-12-23 10:47           ` Óscar Fuentes
2021-12-23 10:50             ` Po Lu
2021-12-23 10:59               ` Óscar Fuentes
2021-12-23 11:05                 ` Po Lu
2021-12-23 11:16                   ` Óscar Fuentes
2021-12-24  4:13           ` Richard Stallman
2021-12-24  4:13         ` Richard Stallman
2021-12-23 10:23       ` Arthur Miller
2021-12-24  4:13         ` Richard Stallman
2021-12-22 14:41   ` xenodasein--- via Emacs development discussions.
  -- strict thread matches above, loose matches on Subject: below --
2021-12-22 17:52 Can we give Eli a break, please? [ Was: Re: Development Speed ] xenodasein--- via Emacs development discussions.
2021-12-22 18:10 xenodasein--- via Emacs development discussions.

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=YcNVm26TFO/eR9dF@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=ofv@wanadoo.es \
    /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.