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
next prev parent 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.