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

Bug#692060: remove shell-command.el from emacs-goodies-el



Dima Kogan <dima@secretsauce.net> writes:

> David Bremner <david@tethera.net> writes:
>
>> Are you willing to maintain it upstream? Because the plan is that
>> emacs-goodies-el is not going to be upstream for anything anymore.
>
> Hi. I just looked at it. If emacs-goodies-el isn't upstream for
> anything, then where are the upstream sources coming from? Are there
> multiple upstreams? In a perfect world would they all go to MELPA and
> emacs-goodies-el would go away?

That's the plan, more or less. We'll see how it goes, but tentatively
emacs-goodies-el could go away post-Buster.

I'm not that set on MELPA-per-se, but rather on having an upstream that
isn't Debian [1]. MELPA is an obvious place for upstreams to distribute
packages but as long as there is version control and releases (and
someone interested in fixing bugs), that's fine.

> It looks like much of shell-command is already available in emacs
> itself, so if there're any pieces that should be preserved, where should
> they go?

Into a separate package if they are substantial enough to warrant it.
If not, that's a bit trickier.  If it's just a few lines of
customization I guess the options include upstream bug-reports (to emacs
in general or to the appropriate package) and a page in emacswiki.org.
Maybe someone-who-is-not-me would be interested in curating a collection
of such bits, but it's not clear to me why that needs to happen
primarily as a Debian package. I guess one possibility is that someone
steps up to maintain a much reduced emacs-goodies-el that would contain
only those bits left over.

[1]: For the avoidance of doubt, I've no objection to Debian package
maintainers being upstream for emacs packages in Debian. I myself
maintain notmuch-emacs upstream, as well as the Debian package.


Reply to: