Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal)

[Stefan Monnier]

>> No: many (most?) savannah gnu projects don't require copyright
>> assignments.  Also, when maintainers disappear, it's rather
>> problematic to get bugs fixed.
> A GNU project is a GNU project, is my understanding. savannah can host
> non-gnu or GNU.  GNU projects all need (C) assignment.  You can't be GNU
> without that.

Of course you can.  Bazaar is/was a GNU project, and its copyright
belongs very clearly to Canonical (who used a similar copyright
assignment principle, except without the same guarantees that they
wouldn't misuse that copyright ;-).

See https://www.gnu.org/help/evaluation.html for details of what it
means to be "a GNU package".

> Maybe that changed?

It's been that way since before Savannah existed, AFAIK.

> I don't see why it's any more easy to get bugs fixed.  If a maintainer
> for a GNU project disappears there's a regular course of action to chase
> them up or hand off control.  Isn't there?  There used to be.

It takes months, going through various intermediaries to get access
rights, ...  Whereas with the current setup I can install a bug fix
as soon as git.sv.gnu.org is back online (oh wait, it is back online!),
without even having to think about it.

> But my comparison is what most authors will experience.

Then they won't contribute to GNU ELPA.  We're no worse, since they
wouldn't contribute to Emacs either.

I don't see the point of making GNU ELPA into a copy of MELPA/Marmalade:
those already exist and they work well, AFAICT.

> I mean that people who want to have an odd build will attempt to make
> the Makefile do it and then break it.

Which Makefile?  elpa/Makefile?  This file is not used directly by
elpa.gnu.org, there's a manual step to update the file used by
elpa.gnu.org, so the risk is very small (as long as someone monitors
the elpa-diffs commits, of course).

> Yes.  But also, my repo is mine.  We have to have discipline around the
> Emacs source tree and I think everyone undestands that's shared.  But the
> expectation surely would be that my branch of the elpa.git is mine.

If you don't want Emacs maintainers to contribute directly to your code,
then elpa.git might indeed not be the best choice for you.

> Really handy vs safe is something I think should err on the side of safe.

Given the general quality of Elisp packages, I'm not sure it's worth the
trouble.  Also, in case there's a packaging bug, you can fix it
trivially with a single commit bumping the version one more time.

> Maybe you don't know enough about software ecosystems?

Maybe.


        Stefan