GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

 >> I hope to polish these over the course of the next few days and
 >> release version 0.2 of the package, which I then request to be added
 >> to GNU ELPA.

 > GNU ELPA is built from a Git repository where development is intended
 > to happen.  So the move does not have to coincide with a release.

	Speaking of the GNU ELPA Git repository, – it seems to be a
	monolithic one (that is: no submodules are used.)  Curiously, is
	there a BCP on maintaining a package in a separate repository
	/and/ keeping its history mirrored in the GNU ELPA one?

	(FWIW, I’d certainly prefer having a repository of my own to
	keep the history of the MW package alone.)

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

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Nic Ferrier]

Ivan Shmakov <ivan@siamics.net> writes:

>>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>  >> I hope to polish these over the course of the next few days and
>  >> release version 0.2 of the package, which I then request to be added
>  >> to GNU ELPA.
>
>  > GNU ELPA is built from a Git repository where development is intended
>  > to happen.  So the move does not have to coincide with a release.
>
> 	Speaking of the GNU ELPA Git repository, – it seems to be a
> 	monolithic one (that is: no submodules are used.)  Curiously, is
> 	there a BCP on maintaining a package in a separate repository
> 	/and/ keeping its history mirrored in the GNU ELPA one?
>
> 	(FWIW, I’d certainly prefer having a repository of my own to
> 	keep the history of the MW package alone.)

I offered marmalade's code base for managing the elpa repository.

It's an upload based system, you just push packages in it.

The code is GPLed so there's no concerns there.

Stefan didn't understand what I meant at the time. Hopefully he does
now.


Nic

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

>> Speaking of the GNU ELPA Git repository, – it seems to be a
>> monolithic one (that is: no submodules are used.)

You get to choose (we call the two options "subtree" and "external").
Auctex, rudel, w3, and a few more are installed as "externals",
i.e. similar to Git submodules (tho hand-managed).

The "external" ones are stored as branches in the same repository
(e.g. the externals/auctex branch).

>> Curiously, is there a BCP on maintaining a package in a separate
>> repository /and/ keeping its history mirrored in the GNU ELPA one?

You can host a mirror elsewhere if you want.  But the elpa repository is
not read-only, so you'll need to pay attention to commits performed
there to keep the two trees in sync.

>> (FWIW, I’d certainly prefer having a repository of my own to
>> keep the history of the MW package alone.)

If you install your package as an "external", then the history is of
course kept separate.

> I offered marmalade's code base for managing the elpa repository.
> It's an upload based system, you just push packages in it.
> The code is GPLed so there's no concerns there.
> Stefan didn't understand what I meant at the time.  Hopefully he does
> now.

Now I understand you suggest we use Marmalade's scripts to manage the
GNU ELPA archive, but I still don't know what that means concretely.

The fact that we have a local storage of the source and VCS history
(with write access so that any Emacs maintainer can install fixes) is an
important design choice.  Would that easily fit into Marmalade's
code base?  How does Marmalade track commits to send them back to the
respective package's maintainer?


        Stefan

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

 >>> Speaking of the GNU ELPA Git repository, – it seems to be a
 >>> monolithic one (that is: no submodules are used.)

 > You get to choose (we call the two options "subtree" and "external").
 > Auctex, rudel, w3, and a few more are installed as "externals",
 > i. e. similar to Git submodules (tho hand-managed).

 > The "external" ones are stored as branches in the same repository
 > (e. g. the externals/auctex branch).

	Despite Git allowing for this (apparently), I tend to consider
	having several root revisions in a single repository somewhat
	confusing.  But I’ve got the idea.

	Why aren’t these managed as Git submodules, BTW?

 >>> Curiously, is there a BCP on maintaining a package in a separate
 >>> repository /and/ keeping its history mirrored in the GNU ELPA one?

 > You can host a mirror elsewhere if you want.  But the elpa repository
 > is not read-only, so you'll need to pay attention to commits
 > performed there to keep the two trees in sync.

	ACK, thanks for clarifying this up.

[…]

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

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

> 	Why aren’t these managed as Git submodules, BTW?

Can't remember.  I did look at them, but they didn't seem to provide
much functionality.  I guess it's mostly a case of NIH.  Tho maybe it
was because submodules can only refer to particular revisions, whereas
we want a reference to "the HEAD".

So should I add your mw as an "external" package?


        Stefan

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Nic Ferrier]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Now I understand you suggest we use Marmalade's scripts to manage the
> GNU ELPA archive, but I still don't know what that means concretely.
>
> The fact that we have a local storage of the source and VCS history
> (with write access so that any Emacs maintainer can install fixes) is an
> important design choice.  Would that easily fit into Marmalade's
> code base?  How does Marmalade track commits to send them back to the
> respective package's maintainer?

It doesn't. You just upload the resulting package.

Hence avoiding the problem of managing the commits. The author does
that.


Nic

Re: GNU ELPA; mw 0.1: modular MediaWiki interface for Emacs

[Stefan Monnier]

>> Now I understand you suggest we use Marmalade's scripts to manage the
>> GNU ELPA archive, but I still don't know what that means concretely.
>> 
>> The fact that we have a local storage of the source and VCS history
>> (with write access so that any Emacs maintainer can install fixes) is an
>> important design choice.  Would that easily fit into Marmalade's
>> code base?  How does Marmalade track commits to send them back to the
>> respective package's maintainer?
> It doesn't. You just upload the resulting package.

Right, so it doesn't provide the features we need :-(


        Stefan

a few questions on GNU ELPA

[Ivan Shmakov]

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

	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?

	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?

	TIA.

[1] https://gnu.org/software/texinfo/manual/texinfo/html_node/All_002dpermissive-Copying-License.html

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

Re: a few questions on GNU ELPA

[Stefan Monnier]

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

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

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


        Stefan

Re: a few questions on GNU ELPA

[Ivan Shmakov]

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

Re: a few questions on GNU ELPA

[Stefan Monnier]

> 	have a trivial .el so licensed in GNU ELPA.  Or will it?

As I said: use a standard GPLv3 blurb and move on.  It's not worth
spending time on this.

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

Sounds fine, yes.


        Stefan