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

[Stephen J. Turnbull]

Nic Ferrier writes:

 > 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.

No, GNU has never tried to monopolize copyright.  A few "strategic"
projects do require assignment or equivalent (mostly those RMS was
directly involved with creating, such as Emacs, of course, and GCC),
and it's recommended for all projects based on experience with license
migrations.  But it's a project by project decision, and always has
been.

 > 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.

Sure, but somebody has recognize that the maintainer has gone AWOL and
then go do the chasing.  This way the bugs reports are shared, to some
extent channels are shared, and it's relatively easy to recognize when
a maintainer has become unresponsive.

Consider the (lack of) success of the "regular course of action"
vis-a-vis Bazaar.  Somebody raised his hand, became the official
maintainer of GNU Bazaar, and has never been heard of again.  The
people who have explicitly disclaimed responsibility for that project
have been far more active!

 > > That depends on what you compare it with.  You're comparing it to having
 > > your package on some random Git server somewhere, but if you compare it
 > > to having your package in Emacs itself, then it's much more "your"
 > > source tree, and it has fewer constraints.
 > 
 > But my comparison is what most authors will experience.

So?  GNU ELPA is part of Emacs, it's not a collection of random packages.

 > Unless you're going to only talk to authors who already contribute to
 > gnu emacs.

s/already/want to/ and you have it!

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

I don't see a difference.

 > >> You're also inviting people to check in non-working code.

Again, I don't see a difference.  Between Emacs core and "some random
Git server somewhere", yes.  Not between ELPA and a separate git
project.  People who check in non-working code in random projects in a
common repository can be slapped hard (I've removed commit privileges
after two warnings to revert, Stefan might or might not be more polite
:-).  Ask Micheal Albinus or Alan Mackenzie how often random people
have broken TRAMP or CC-mode in the XEmacs package repo.  It just
doesn't need to happen, because core and the ELPA projects are
different.  The people who maintain Emacs core are grownups, they
don't think that because they're "core" that gives them rights to mess
with projects they're only loosely associated with.

 > > I'd accept patches to the GNU ELPA scripts which lets authors do that.
 > > Note that I've heard comments from other authors who find the "just bump
 > > the version number" way of making a release to be really handy, so
 > > I wouldn't want to force people to make their own archive.
 > 
 > Really handy vs safe is something I think should err on the side of
 > safe.

"Bump the version number" has worked for XEmacs for a decade.  I don't
recall any packaging bugs of the "somebody broke make bootstrap, just
needs a trivial patch" level.

 > >> I mean: You're doing something very weird. Why?
 > >
 > > I guess I just don't know what's weird about it.
 > 
 > Maybe you don't know enough about software ecosystems?

Maybe you don't know enough about Emacs and GNU? :-)  Specifically, the
term "software ecosystem" is deprecated here.  You'd have to read the
FSF FAQ or ask RMS for the party line, but my take on it is that the
FSF and GNU have taken the role of guardian (legal and developer,
repectively) of software freedom, and decisions are taken explicitly
about project and Project organization as well as specific development
practices, and even features, in the interest of free software.
Decisions in these matters are not based on "natural ecological"
relationships among participants.

Note well: In practice, although I'd quibble about details, I prefer
to run things basically in the way you suggest.  But that is not the
way things are done in Emacs or in the free software movement
(vs. open source community) in general.

Regards,