emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a few questions on GNU ELPA


From: Ivan Shmakov
Subject: Re: a few questions on GNU ELPA
Date: Fri, 30 Jan 2015 20:24:39 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

>>>>> Stefan Monnier <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]