Re: Why not include all ELPA packages in an Emacs release?

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> Packages that will be moved to ELPA (when that happens) should have
> their dedicated maintainers, and it will be the job of those
> maintainers to adapt to any changes in Emacs that affect each package.
>
> I see no show-stoppers there, FWIW.

Does Calc, or its ilk?  And will such maintainers notice and be willing
to adapt their packages to minor changes that don't affect themselves
and their existing users, as,

2023-06-26  Po Lu  <luangruo@yahoo.com>

	* lisp/calc/calc.el (calc-mode, calc): Make sure the on-screen
	keyboard is not hidden when a Calc buffer is created or a Calc
	Trail window is being created for the first time.

	* lisp/touch-screen.el (touch-screen-window-selection-changed):
	Take touch-screen-display-keyboard in to account.

during the development cycle of a new feature in a new Emacs release, as
was done here?  Had Calc been transferred into an independent
repository, with its own maintainers, these changes would have been
considerably delayed at best, depriving Android users of a functioning
scientific calculator in the interim.  Alternatively, we would have been
obliged to install this ourselves, in the ELPA repository, which you'll
agree, if you recall installing changesets as individual changes to each
modified file, is essentially no different from that, just with the
additional user burden of updating.  Another example:

2023-01-24  Po Lu  <luangruo@yahoo.com>

	* lisp/cedet/semantic/db-ebrowse.el
	(semanticdb-create-ebrowse-database):
	* lisp/gnus/mail-source.el (mail-source-movemail-program):
	* lisp/hexl.el (hexl-program):
	* lisp/htmlfontify.el (hfy-etags-bin):
	* lisp/ielm.el (inferior-emacs-lisp-mode):
	* lisp/mail/rmail.el (rmail-autodetect):
	(rmail-insert-inbox-text):
	* lisp/org/org-ctags.el (org-ctags-path-to-ctags):
	* lisp/progmodes/cperl-mode.el (cperl-etags):
	* lisp/speedbar.el (speedbar-fetch-etags-command):
	* lisp/textmodes/reftex-global.el (reftex-create-tags-file): Use
	new variables.

and indeed the modification to org-ctags.el was, until two days ago,
absent from the version of Org maintained by its dedicated maintainers.

> The issues which led us to seriously consider moving some core
> packages to ELPA are not imaginary, they are very real.

Which issues and packages are you speaking of?