all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ivan Shmakov <ivan@siamics.net>
To: emacs-devel@gnu.org
Subject: Re: a few questions on GNU ELPA
Date: Fri, 30 Jan 2015 20:24:39 +0000	[thread overview]
Message-ID: <87iofohv94.fsf@violet.siamics.net> (raw)
In-Reply-To: <jwvegqdefxp.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Thu, 29 Jan 2015 11:06:11 -0500")

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

 >> Reading elpa/README left me with a few unanswered questions.  First
 >> of all, – when the package is of the multi-file variety, would the
 >> “release machinery” be somehow offended should I import the
 >> pre-release history /without/ the respective PKG/PKG.el file, – used
 >> (AIUI) for its Version: metadata field?  (I’ll then push that file
 >> in a separate “release” commit.)

 > If the <pkg>.el file is missing from the HEAD revision, the nightly
 > deployment scripts may complain (to me), but if it's just missing in
 > some previous revision, that's of no consequence.

	ACK, thanks.

 >> Now, that same file is going to have a dozen lines of code
 >> (excluding comments) at most (that is: mainly the ‘defgroup’ and
 >> ‘provide’ forms.)  Should I use the GPL3+ notice for that file (as
 >> the rest of the code uses), or would the simple all-permissive
 >> license [1] be also acceptable?

 > For auctex.el I just used the standard GPL3 notice.  Saved me some
 > valuable thinking ;-)

	I believe that claiming GPLv3+ over a file which is probably not
	copyrightable in the first place is somewhat misleading.

	Furthermore, given that Emacs itself has files bearing that same
	notice (see leim/MISC-DIC/cangjie-table.cns, for instance, and
	also a few more also under leim/), I guess it will do no harm to
	have a trivial .el so licensed in GNU ELPA.  Or will it?

 >> Also regarding the release machinery, do I understand it correctly
 >> that there’s currently no way to maintain several (say,
 >> “development” and “stable”) branches in GNU ELPA?

 > That's right.  Of course, you can keep a "development" branch
 > somewhere in elpa.git if you want, but the GNU ELPA deployment
 > scripts won't know anything about it.

	ACK, thanks.

	BTW, as the resulting .tar file is going to differ to the one
	I’ve previously made available, does it make sense to use
	something like 0.1.1 for the GNU ELPA version, so to avoid the
	availability of two /different/ mw-0.1.tar files?  (I’d rather
	use something like 0.1-elpa instead, but that isn’t going to be
	accepted by version-to-list.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A



  reply	other threads:[~2015-01-30 20:24 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87oatpkof7.fsf@passepartout.tim-landscheidt.de>
2014-10-11 10:55 ` bug#18687: mw 0.1: modular MediaWiki interface for Emacs Ivan Shmakov
2014-10-12  4:47   ` Stefan Monnier
2014-10-12 10:20     ` Ivan Shmakov
2014-10-14 18:40       ` Stefan Monnier
2014-10-14 20:05         ` Ivan Shmakov
     [not found]         ` <87k342zabt.fsf@violet.siamics.net>
2014-10-14 23:51           ` Stefan Monnier
2014-10-15 10:27             ` GNU ELPA; " Ivan Shmakov
2014-10-15 13:35               ` Nic Ferrier
2014-10-15 17:51                 ` Stefan Monnier
2014-10-15 18:42                   ` Ivan Shmakov
2014-10-15 22:38                     ` Stefan Monnier
2014-10-15 18:51                   ` Nic Ferrier
2014-10-15 22:31                     ` Stefan Monnier
2014-10-21 16:33             ` bug#18687: " Stefan Monnier
2014-10-22 21:35               ` Ivan Shmakov
2014-10-24 18:55                 ` Ivan Shmakov
2014-12-31 12:12                   ` bug#18687: mw: " Ivan Shmakov
2015-01-01 16:06                     ` Stefan Monnier
2015-01-01 16:37                       ` Ivan Shmakov
2015-01-23 14:42                       ` Ivan Shmakov
2015-01-29 13:45                         ` a few questions on GNU ELPA Ivan Shmakov
2015-01-29 16:06                           ` Stefan Monnier
2015-01-30 20:24                             ` Ivan Shmakov [this message]
2015-01-31  6:31                               ` Stefan Monnier
2015-02-20 17:14                         ` bug#18687: mw: modular MediaWiki interface for Emacs Stefan Monnier
2015-02-20 18:30                           ` Ivan Shmakov
2015-02-20 19:52                             ` Stefan Monnier
2015-01-01 21:03                     ` Ivan Shmakov
2015-02-20  7:09                     ` Ivan Shmakov
2020-02-29 18:39     ` bug#18687: mw 0.1: " Stefan Kangas
2020-02-29 19:55       ` Ivan Shmakov
2020-03-01  1:38         ` Stefan Kangas
2020-03-08 17:52           ` Stefan Monnier
2020-08-04 16:06             ` Stefan Kangas
2020-08-04 16:45               ` Mark A. Hershberger
2020-08-04 16:47                 ` Stefan Kangas
2020-03-02 20:30       ` Mark A. Hershberger
2020-03-11  1:31         ` Stefan Kangas
2014-10-13 17:20   ` Mark A. Hershberger

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=87iofohv94.fsf@violet.siamics.net \
    --to=ivan@siamics.net \
    --cc=emacs-devel@gnu.org \
    /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.