all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Nic Ferrier <nferrier@ferrier.me.uk>
Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
Subject: Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal)
Date: Wed, 12 Nov 2014 18:31:11 -0500	[thread overview]
Message-ID: <jwvlhng3taq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87bnocgh1r.fsf@ferrier.me.uk> (Nic Ferrier's message of "Wed, 12 Nov 2014 23:01:04 +0000")

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



  reply	other threads:[~2014-11-12 23:31 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07 13:45 package.el, auto-installation, and auto-removal Stefan Monnier
2014-11-07 14:12 ` Ted Zlatanov
2014-11-07 19:50   ` joakim
2014-11-08  4:27     ` Stefan Monnier
2014-11-10 14:55   ` Phillip Lord
2014-11-10 17:46     ` Ted Zlatanov
2014-11-10 20:27       ` Nic Ferrier
2014-11-10 21:49         ` Stefan Monnier
2014-11-10 22:02           ` package and testing rant (was Re: package.el, auto-installation, and auto-removal) Nic Ferrier
2014-11-10 23:24             ` Stefan Monnier
2014-11-11  2:53               ` Drew Adams
2014-11-11 11:41               ` Nic Ferrier
2014-11-11 16:03                 ` Eli Zaretskii
2014-11-11 17:17                   ` Nic Ferrier
2014-11-11 17:20                   ` Stefan Monnier
2014-11-11 17:53                     ` Eli Zaretskii
2014-11-11 16:24                 ` Stefan Monnier
2014-11-11 17:15                   ` Nic Ferrier
2014-11-11 15:57               ` Eli Zaretskii
2014-11-11 17:18                 ` Stefan Monnier
2014-11-11 17:52                   ` Eli Zaretskii
2014-11-11 18:04                     ` David Kastrup
2014-11-12  3:20                       ` Stephen J. Turnbull
2014-11-12  6:48                         ` David Kastrup
2014-11-11 17:27                 ` Nic Ferrier
2014-11-11 18:20               ` Achim Gratz
2014-11-12 16:13                 ` Stefan Monnier
2014-11-12 17:00                   ` Stephen Leake
2014-11-12 17:51                   ` Nic Ferrier
2014-11-12 20:34                     ` Stefan Monnier
2014-11-12 21:39                       ` Nic Ferrier
2014-11-12 22:40                         ` Stefan Monnier
2014-11-12 23:01                           ` Nic Ferrier
2014-11-12 23:31                             ` Stefan Monnier [this message]
2014-11-13  1:09                             ` Stephen J. Turnbull
2014-11-13  5:06                             ` Richard Stallman
2014-11-13 14:59                               ` Nic Ferrier
2014-11-15 17:09                             ` Stephen Leake
2014-11-15 18:20                               ` Nic Ferrier
2014-11-16  3:49                                 ` Stefan Monnier
2014-11-13  8:18                           ` Thien-Thi Nguyen
2014-11-13 10:53                         ` Phillip Lord
2014-11-13 14:54                           ` Nic Ferrier
2014-11-14 11:04                             ` Phillip Lord
2014-11-14 22:56                               ` Nic Ferrier
2014-11-12 18:15                   ` Achim Gratz
2014-11-12 22:21                     ` Stefan Monnier
2014-11-13 20:21                       ` Achim Gratz
2014-11-12 13:05               ` Stephen Leake
2014-11-11 13:30             ` Phillip Lord
2014-11-11 14:12               ` Nic Ferrier
2014-11-11 16:26                 ` Stefan Monnier
2014-11-11 17:13                   ` Nic Ferrier
2014-11-12 16:14                     ` Stefan Monnier
2014-11-12 17:02                       ` Stephen Leake
2014-11-12 17:21                         ` Stefan Monnier
2014-11-10 21:37       ` package.el, auto-installation, and auto-removal Stefan Monnier
2014-11-11  1:29         ` Ted Zlatanov
2014-11-11  2:26           ` Stefan Monnier
2014-11-11  2:59             ` Ted Zlatanov
2014-11-11  3:55               ` Stefan Monnier
2014-11-11 12:44                 ` Phillip Lord
2014-11-11 13:31                   ` Nic Ferrier
2014-11-11 11:31             ` Nic Ferrier
2014-11-11 16:22               ` Stefan Monnier
2014-11-11 17:10                 ` Nic Ferrier
2014-11-11 19:36                   ` Achim Gratz
2014-11-11 20:40                     ` Nic Ferrier
2014-11-11 21:53                       ` Stefan Monnier
2014-11-12 22:17                         ` Nic Ferrier
2014-11-12 22:59                           ` Stefan Monnier
2014-11-12 23:26                             ` Nic Ferrier
2014-11-13  0:21                               ` Stefan Monnier
2014-11-07 20:00 ` Nic Ferrier
2014-11-08  4:29   ` Stefan Monnier
2014-11-08 23:18     ` Nic Ferrier
2014-11-09  3:17       ` Stefan Monnier

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

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

  git send-email \
    --in-reply-to=jwvlhng3taq.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=Stromeko@nexgo.de \
    --cc=emacs-devel@gnu.org \
    --cc=nferrier@ferrier.me.uk \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.