unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: John Task <q01@disroot.org>
Cc: emacs-devel@gnu.org
Subject: Re: [NonGNU Elpa] New package: ETT
Date: Wed, 03 May 2023 21:05:03 +0300	[thread overview]
Message-ID: <83ttwtl29c.fsf@gnu.org> (raw)
In-Reply-To: <86a5ylbadn.fsf@disroot.org> (message from John Task on Wed, 03 May 2023 14:14:50 -0300)

> From: John Task <q01@disroot.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 03 May 2023 14:14:50 -0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Anyway, did you consider extending existing packages with those modern
> > features, instead of making a completely new separate package?
> 
> [...]
> I get your intentions, but all things considered, I think everything
> is better as is.

From your POV, no doubt.  I'm well familiar with the joy of designing
my own package or feature from the ground up, unburdened by history,
backward compatibility, and all that ballast.  If nothing else, it's a
lot of fun.

But from the project management POV (which is the hat I'm wearing
now), it is a problem if, instead of developing and extending existing
packages, we keep introducing new and different ones.  It makes Emacs
as a whole harder for users to learn and follow for years to come:
they can never be sure the packages they use and are familiar with
will not be abandoned and replaced by others which they will need to
learn from scratch.  It also presents hard maintenance dilemmas for
which there are no good answers: should we have multiple packages with
partially overlapping functionalities, or should we abandon the old
one and embrace the new one(s)?

This is why extending an existing package, although it is harder and
requires more efforts from the developers, is always preferred here to
additions of new and incompatible ones.  E.g., timeclock could have a
"time-tracking" feature or mode added to it, where it would target the
usage patterns you had in mind, rather than the original purpose of
timeclock (which still has its merit, btw, and many smartphone apps
which do just that are a living proof of that).  And, of course,
statistics and graphs can be added to any existing feature, it doesn't
IMO justify a new package written from the ground up.

Of course, I'm too old to naïvely believe that any of the above will
convince anyone to scratch a different itch.



  reply	other threads:[~2023-05-03 18:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 17:14 [NonGNU Elpa] New package: ETT John Task
2023-05-03 18:05 ` Eli Zaretskii [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-05-03 18:06 John Task
2023-05-03 15:29 John Task
2023-05-03 16:57 ` Sam Steingold
2023-05-03 15:02 John Task
2023-05-03 16:41 ` Philip Kaludercic
2023-05-03 14:07 John Task
2023-05-03 15:55 ` Eli Zaretskii
2023-05-02 21:21 John Task
2023-05-03  6:08 ` Philip Kaludercic
2023-05-03  6:11   ` Philip Kaludercic
2023-05-03  7:12   ` Yuri Khan
2023-05-03 11:12 ` Eli Zaretskii
2023-03-01 18:17 John Task
2023-03-01 17:46 John Task
2023-03-02  4:33 ` Richard Stallman
2023-03-02 10:08   ` Holger Schurig
2023-03-02 14:50 ` q01
2023-03-02 15:55 ` John Task

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ttwtl29c.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=q01@disroot.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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).