having emacs-matlab in ELPA, finally. FSF paper signed

having emacs-matlab in ELPA, finally. FSF paper signed

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]


Hi all

After quite a bit of time I can say the following :

    1) All authors/contributors have either signed the corresponding FSF
       papers, in the very few cases where they have not, their
       corresponding code has been completely removed and therefore
       matlab-emacs could be in ELPA. Eli gave me his ok. (And RMS a
       while ago, if all legal requirements would be satisfied, of course).

    2) Can someone please provide me with some information or a link how
       to proceed? I have to say that we, the authors, are now cleaning
       up a bit the repository, rebase, delete obselete branches etc,
       before including the package in ELPA.

    3) I also have to tell you that the authors working for mathworks,
       want the main development taking place in github, since it would
       be easier to have pull/merge requests. I hope this will not cause
       any problems.

    4) However, I will ensure that only commits will end up in ELPA, if
       the corresponding authors have signed the FSF papers.

Regards


Uwe Brauer 


-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5684 bytes --]

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Andrea Corallo]

Uwe Brauer <oub@mat.ucm.es> writes:

> Hi all
>
> After quite a bit of time I can say the following :
>
>     1) All authors/contributors have either signed the corresponding FSF
>        papers, in the very few cases where they have not, their
>        corresponding code has been completely removed and therefore
>        matlab-emacs could be in ELPA. Eli gave me his ok. (And RMS a
>        while ago, if all legal requirements would be satisfied, of course).

Hi,

that's great news!

>     2) Can someone please provide me with some information or a link how
>        to proceed? I have to say that we, the authors, are now cleaning
>        up a bit the repository, rebase, delete obselete branches etc,
>        before including the package in ELPA.

The ELPA README is the place to start from
<https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README>

>     3) I also have to tell you that the authors working for mathworks,
>        want the main development taking place in github, since it would
>        be easier to have pull/merge requests. I hope this will not cause
>        any problems.

This is not a problem, if I count them correctly we host 236 ELPA
packages developed on github ATM.

>     4) However, I will ensure that only commits will end up in ELPA, if
>        the corresponding authors have signed the FSF papers.

Thanks!

  Andrea

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

>>> "AC" == Andrea Corallo <acorallo@gnu.org> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>> Hi all
>> 
>> After quite a bit of time I can say the following :
>> 
>> 1) All authors/contributors have either signed the corresponding FSF
>> papers, in the very few cases where they have not, their
>> corresponding code has been completely removed and therefore
>> matlab-emacs could be in ELPA. Eli gave me his ok. (And RMS a
>> while ago, if all legal requirements would be satisfied, of course).

> Hi,

> that's great news!

>> 2) Can someone please provide me with some information or a link how
>> to proceed? I have to say that we, the authors, are now cleaning
>> up a bit the repository, rebase, delete obselete branches etc,
>> before including the package in ELPA.

> The ELPA README is the place to start from
> <https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README>

Thanks for this pointer. I had a first glance, it reminds me very much
on the xemacs package system (but that used mercurial not git😉). 

I have to read it in more details, but so far, I have two questions.

    1. The name of the branches is fixed, that is the principal branch
       has to be called main (and couldn't be called say default?)

    2. Matlab is right now in MELPA and it seems much simpler to add a
       package to MELPA than to ELPA. Is one of the reasons, the github
       interface MELPA uses, but ELPA is bound to savannah that does not
       provide something similar?

Regards

Uwe 
-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5684 bytes --]

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Andrea Corallo]

Uwe Brauer <oub@mat.ucm.es> writes:

>>>> "AC" == Andrea Corallo <acorallo@gnu.org> writes:
>
>> Uwe Brauer <oub@mat.ucm.es> writes:
>>> Hi all
>>> 
>>> After quite a bit of time I can say the following :
>>> 
>>> 1) All authors/contributors have either signed the corresponding FSF
>>> papers, in the very few cases where they have not, their
>>> corresponding code has been completely removed and therefore
>>> matlab-emacs could be in ELPA. Eli gave me his ok. (And RMS a
>>> while ago, if all legal requirements would be satisfied, of course).
>
>> Hi,
>
>> that's great news!
>
>>> 2) Can someone please provide me with some information or a link how
>>> to proceed? I have to say that we, the authors, are now cleaning
>>> up a bit the repository, rebase, delete obselete branches etc,
>>> before including the package in ELPA.
>
>> The ELPA README is the place to start from
>> <https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README>
>
> Thanks for this pointer. I had a first glance, it reminds me very much
> on the xemacs package system (but that used mercurial not git😉). 
>
> I have to read it in more details, but so far, I have two questions.
>
>     1. The name of the branches is fixed, that is the principal branch
>        has to be called main (and couldn't be called say default?)

Not an ELPA expert here but AFAIU the branch your community is using to
produce releases can be called as you prefer, see the decription of
:release-branch in README.

>     2. Matlab is right now in MELPA and it seems much simpler to add a
>        package to MELPA than to ELPA. Is one of the reasons, the github
>        interface MELPA uses, but ELPA is bound to savannah that does not
>        provide something similar?

I'm not sure why you think the MELPA process should be easier, adding
emacs-matlab to ELPA should be like a three line patch to
<https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages>
where we just specify package-name, url and release-branch no?

You can submit the patch here or if these three parameters are known we
can write and push the patch for you :)

Thanks

  Andrea

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

Uwe Brauer <oub@mat.ucm.es> writes:

>>>> "AC" == Andrea Corallo <acorallo@gnu.org> writes:
>
>> Uwe Brauer <oub@mat.ucm.es> writes:
>>> Hi all
>>> 
>>> After quite a bit of time I can say the following :
>>> 
>>> 1) All authors/contributors have either signed the corresponding FSF
>>> papers, in the very few cases where they have not, their
>>> corresponding code has been completely removed and therefore
>>> matlab-emacs could be in ELPA. Eli gave me his ok. (And RMS a
>>> while ago, if all legal requirements would be satisfied, of course).
>
>> Hi,
>
>> that's great news!
>
>>> 2) Can someone please provide me with some information or a link how
>>> to proceed? I have to say that we, the authors, are now cleaning
>>> up a bit the repository, rebase, delete obselete branches etc,
>>> before including the package in ELPA.
>
>> The ELPA README is the place to start from
>> <https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README>
>
> Thanks for this pointer. I had a first glance, it reminds me very much
> on the xemacs package system (but that used mercurial not git😉). 
>
> I have to read it in more details, but so far, I have two questions.
>
>     1. The name of the branches is fixed, that is the principal branch
>        has to be called main (and couldn't be called say default?)

Packages usually don't have to deal with that, all the ELPA build system
needs is a git repository URL, and that is usually enough to figure out
the rest.  If it uses some unconventional branch name that is not
default, we just need to note that in the package specification.

>     2. Matlab is right now in MELPA and it seems much simpler to add a
>        package to MELPA than to ELPA. Is one of the reasons, the github
>        interface MELPA uses, but ELPA is bound to savannah that does not
>        provide something similar?

So this is the host: https://sourceforge.net/projects/matlab-emacs/?

IIRC MELPA forces contributors to write their own package
specifications, right?  Some people do that for ELPA, but it is not
expected (I usually find it easier to update elpa.git myself).  In this
case, the basic specification is just:


[-- Attachment #2: Type: text/plain, Size: 595 bytes --]

diff --git a/matlab-shell.el b/matlab-shell.el
index ee80555bee..07c6223137 100644
--- a/matlab-shell.el
+++ b/matlab-shell.el
@@ -1003,7 +1003,7 @@ Sends commands to the MATLAB shell to initialize the MATLAB process."
 	     (ecca (if ecc (format "emacs.set('clientcmd', '%s');" ecc) ""))
 	     (args (list nsa ecca))
 	     (cmd (format "run('%s');%s" initcmd (apply 'concat args))))
-	(matlab-shell-send-command cmd)
+	(matlab-shell-send-command (string-replace (expand-file-name "~/") "~/" cmd))
 	)
     
     ;; Setup is misconfigured - we need emacsinit because it tells us how to debug

[-- Attachment #3: Type: text/plain, Size: 198 bytes --]


Though right now the package doesn't build, as the package is not well
formed according to (elisp) Packaging.  Among other things, it lacks a
"Version" header.

-- 
	Philip Kaludercic on peregrine

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Andreas Schwab]

On Aug 12 2024, Philip Kaludercic wrote:

> diff --git a/matlab-shell.el b/matlab-shell.el
> index ee80555bee..07c6223137 100644
> --- a/matlab-shell.el
> +++ b/matlab-shell.el
> @@ -1003,7 +1003,7 @@ Sends commands to the MATLAB shell to initialize the MATLAB process."
>  	     (ecca (if ecc (format "emacs.set('clientcmd', '%s');" ecc) ""))
>  	     (args (list nsa ecca))
>  	     (cmd (format "run('%s');%s" initcmd (apply 'concat args))))
> -	(matlab-shell-send-command cmd)
> +	(matlab-shell-send-command (string-replace (expand-file-name "~/") "~/" cmd))

aka abbreviate-file-name

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> On Aug 12 2024, Philip Kaludercic wrote:
>
>> diff --git a/matlab-shell.el b/matlab-shell.el
>> index ee80555bee..07c6223137 100644
>> --- a/matlab-shell.el
>> +++ b/matlab-shell.el
>> @@ -1003,7 +1003,7 @@ Sends commands to the MATLAB shell to initialize the MATLAB process."
>>  	     (ecca (if ecc (format "emacs.set('clientcmd', '%s');" ecc) ""))
>>  	     (args (list nsa ecca))
>>  	     (cmd (format "run('%s');%s" initcmd (apply 'concat args))))
>> -	(matlab-shell-send-command cmd)
>> +	(matlab-shell-send-command (string-replace (expand-file-name "~/") "~/" cmd))
>
> aka abbreviate-file-name

Uh, wrong patch (don't even remember touching that file?):


[-- Attachment #2: Type: text/plain, Size: 434 bytes --]

diff --git a/elpa-packages b/elpa-packages
index f320d79dd7..7954d9062f 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -482,6 +482,7 @@
   :ignored-files ("LICENSE"))
  (markchars		:url nil)
  (math-symbol-lists 	:url "https://github.com/vspinu/math-symbol-lists.git")
+ (matlab		:url "https://git.code.sf.net/p/matlab-emacs/src")
  (mct			:url "https://gitlab.com/protesilaos/mct"
   :doc "README.org")
  (memory-usage		:url nil)

[-- Attachment #3: Type: text/plain, Size: 37 bytes --]


-- 
	Philip Kaludercic on peregrine

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]


> Uwe Brauer <oub@mat.ucm.es> writes:

> Packages usually don't have to deal with that, all the ELPA build system
> needs is a git repository URL, and that is usually enough to figure out
> the rest.  If it uses some unconventional branch name that is not
> default, we just need to note that in the package specification.

Ok


> So this is the host: https://sourceforge.net/projects/matlab-emacs/?

Aeh, well yes and no. This is, still the main repository for your
development. But lately, especially the authors working for matlab,
would  like to move the main development to github, because of its
interface, pull requests etc (I am not a huge fan though 😬).

But before we move I would like to clean up the repository a bit,
deleting obsolete branches, rebasing this sort of things, and there is
still a branch, not merged with master whose status is unclear.

The next thing is then to check the headers of the files etc.

An issue that worries me is this. If out of a sudden a lot of new
contributions pop up, then I have to think of having a separate branch,
say called ELPA in which all authors have signed the FSF papers and
main/default the main development branch. I have still not made my mine


> IIRC MELPA forces contributors to write their own package
> specifications, right?

Yes a so called recipy files and then you have to do a pull request,
sigh 😬

>   Some people do that for ELPA, but it is not
> expected (I usually find it easier to update elpa.git myself).  In this
> case, the basic specification is just:

> diff --git a/matlab-shell.el b/matlab-shell.el
> index ee80555bee..07c6223137 100644
> --- a/matlab-shell.el
> +++ b/matlab-shell.el
> @@ -1003,7 +1003,7 @@ Sends commands to the MATLAB shell to initialize the MATLAB process."
>  	     (ecca (if ecc (format "emacs.set('clientcmd', '%s');" ecc) ""))
>  	     (args (list nsa ecca))
>  	     (cmd (format "run('%s');%s" initcmd (apply 'concat args))))
> -	(matlab-shell-send-command cmd)
> +	(matlab-shell-send-command (string-replace (expand-file-name "~/") "~/" cmd))
>  	)
     
>      ;; Setup is misconfigured - we need emacsinit because it tells us how to debug

Thanks I will have look later

> Though right now the package doesn't build, as the package is not well
> formed according to (elisp) Packaging.  Among other things, it lacks a
> "Version" header.

Yes, I know on my TODO list, but I want to finish the cleanup process fist




-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5684 bytes --]

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Philip Kaludercic]

Uwe Brauer <oub@mat.ucm.es> writes:

>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> Packages usually don't have to deal with that, all the ELPA build system
>> needs is a git repository URL, and that is usually enough to figure out
>> the rest.  If it uses some unconventional branch name that is not
>> default, we just need to note that in the package specification.
>
> Ok
>
>
>> So this is the host: https://sourceforge.net/projects/matlab-emacs/?
>
> Aeh, well yes and no. This is, still the main repository for your
> development. But lately, especially the authors working for matlab,
> would  like to move the main development to github, because of its
> interface, pull requests etc (I am not a huge fan though 😬).
>
> But before we move I would like to clean up the repository a bit,
> deleting obsolete branches, rebasing this sort of things, and there is
> still a branch, not merged with master whose status is unclear.
>
> The next thing is then to check the headers of the files etc.
>
> An issue that worries me is this. If out of a sudden a lot of new
> contributions pop up, then I have to think of having a separate branch,
> say called ELPA in which all authors have signed the FSF papers and
> main/default the main development branch. I have still not made my mine

I am afraid I don't understand what you are trying to say here.  It is
true that you should check if new contributors have signed the FSF CA,
but how does that related to Git branches?

>> IIRC MELPA forces contributors to write their own package
>> specifications, right?
>
> Yes a so called recipy files and then you have to do a pull request,
> sigh 😬
>
>>   Some people do that for ELPA, but it is not
>> expected (I usually find it easier to update elpa.git myself).  In this
>> case, the basic specification is just:
>
>> diff --git a/matlab-shell.el b/matlab-shell.el
>> index ee80555bee..07c6223137 100644
>> --- a/matlab-shell.el
>> +++ b/matlab-shell.el
>> @@ -1003,7 +1003,7 @@ Sends commands to the MATLAB shell to initialize the MATLAB process."
>>  	     (ecca (if ecc (format "emacs.set('clientcmd', '%s');" ecc) ""))
>>  	     (args (list nsa ecca))
>>  	     (cmd (format "run('%s');%s" initcmd (apply 'concat args))))
>> -	(matlab-shell-send-command cmd)
>> +	(matlab-shell-send-command (string-replace (expand-file-name "~/") "~/" cmd))
>>  	)
>      
>>      ;; Setup is misconfigured - we need emacsinit because it tells us how to debug
>
> Thanks I will have look later

Disregard this, I seem to have attached the wrong diff.

>> Though right now the package doesn't build, as the package is not well
>> formed according to (elisp) Packaging.  Among other things, it lacks a
>> "Version" header.
>
> Yes, I know on my TODO list, but I want to finish the cleanup process fist

OK, just ping me when you think the cleanup process is done, and I can
tell you if anything remains to be done before adding the package.

-- 
	Philip Kaludercic on peregrine

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]


> Uwe Brauer <oub@mat.ucm.es> writes:

> I am afraid I don't understand what you are trying to say here.  It is
> true that you should check if new contributors have signed the FSF CA,
> but how does that related to Git branches?

Sorry for not having explained this better. Once we have moved to github
(which I hoped to have done already), there are two scenarios

    1. We proceed as before, that is around 4 authors, all of them
       having signed the FSF paper, continue to contribute.

    2. Out of sudden, because it is github and a people love pull
       requests, a lot of contributions pop up, maybe from people
       working for matlab, or for any other reasons. These contributions
       might introduce new sexy features or bug fixes or both, but the
       authors are somehow lazy to sign the FSF papers (it was quite a
       bit of ordeal to have all contributors signed). In that scenario,
       it might be a good idea to have 2 branches,

       1. one for commits with authos having signed the FSF papers

       2. One for commits with new contributions but with non-FSF
          authors.
          

From experience it is best to be prepared. I know git is flexible: I can
create, rename and delete branches, but because git is so flexible the
process is not failsafe, name-rev does not always assign to a commit the
correct branch, which makes me nervous (being a mercurial user).


> Disregard this, I seem to have attached the wrong diff.

Ok. 

> OK, just ping me when you think the cleanup process is done, and I can
> tell you if anything remains to be done before adding the package.

Hopefully soon.


-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the EU and NATO membership of Ukraine. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5684 bytes --]

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Philip Kaludercic]

Uwe Brauer <oub@mat.ucm.es> writes:

>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> I am afraid I don't understand what you are trying to say here.  It is
>> true that you should check if new contributors have signed the FSF CA,
>> but how does that related to Git branches?
>
> Sorry for not having explained this better. Once we have moved to github
> (which I hoped to have done already), 

BTW, I forgot to mention that I can also recommend Codeberg, if it is
just the UI you care about.

>                                       there are two scenarios
>
>     1. We proceed as before, that is around 4 authors, all of them
>        having signed the FSF paper, continue to contribute.
>
>     2. Out of sudden, because it is github and a people love pull
>        requests, a lot of contributions pop up, maybe from people
>        working for matlab, or for any other reasons. These contributions
>        might introduce new sexy features or bug fixes or both, but the
>        authors are somehow lazy to sign the FSF papers (it was quite a
>        bit of ordeal to have all contributors signed). In that scenario,
>        it might be a good idea to have 2 branches,
>
>        1. one for commits with authos having signed the FSF papers
>
>        2. One for commits with new contributions but with non-FSF
>           authors.

Hmm, I have never heard of this kind of a model, usually a pull request
would just stay open until the person has signed the documents.  The
main issue I'd anticipate is that it would become difficult to keep an
overview of what was contributed by someone having signed the CA and
not, causing fragmentation and a higher burden of maintenance.

>
> From experience it is best to be prepared. I know git is flexible: I can
> create, rename and delete branches, but because git is so flexible the
> process is not failsafe, name-rev does not always assign to a commit the
> correct branch, which makes me nervous (being a mercurial user).
>
>
>> Disregard this, I seem to have attached the wrong diff.
>
> Ok. 
>
>> OK, just ping me when you think the cleanup process is done, and I can
>> tell you if anything remains to be done before adding the package.
>
> Hopefully soon.

-- 
	Philip Kaludercic on peregrine

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]


> Uwe Brauer <oub@mat.ucm.es> writes:

> BTW, I forgot to mention that I can also recommend Codeberg, if it is
> just the UI you care about.

Thanks, I don't care about the UI, I prefer the command line or emacs
for that matter.
The others want github (I even would have preferred gitlab)


> Hmm, I have never heard of this kind of a model, usually a pull
> request would just stay open until the person has signed the
> documents. The main issue I'd anticipate is that it would become
> difficult to keep an overview of what was contributed by someone
> having signed the CA and not, causing fragmentation and a higher
> burden of maintenance.

Yeah, the  longer  I think about it the more I come to the conclusion that
it should be  a method of last, well, very last resort.




-- 
I strongly condemn Hamas heinous despicable pogroms/atrocities on Israel
I strongly condemn Putin's war of aggression against Ukraine. I support
to deliver weapons to Ukraine's military. I support the EU and NATO
membership of Ukraine.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5684 bytes --]

Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Philip Kaludercic]

Uwe Brauer <oub@mat.ucm.es> writes:

>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> BTW, I forgot to mention that I can also recommend Codeberg, if it is
>> just the UI you care about.
>
> Thanks, I don't care about the UI, I prefer the command line or emacs
> for that matter.
> The others want github (I even would have preferred gitlab)

FWIW Codeberg would allow logging in using a GitHub account, while not
depending on non-free software IIRC (and generally minimising Javascript
where unnecessary).

>> Hmm, I have never heard of this kind of a model, usually a pull
>> request would just stay open until the person has signed the
>> documents. The main issue I'd anticipate is that it would become
>> difficult to keep an overview of what was contributed by someone
>> having signed the CA and not, causing fragmentation and a higher
>> burden of maintenance.
>
> Yeah, the  longer  I think about it the more I come to the conclusion that
> it should be  a method of last, well, very last resort.

1+

-- 
	Philip Kaludercic on peregrine