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

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

[Uwe Brauer]

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


Hi


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

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


Ok, we finished some weeks ago but also had to merge some branches with new features. 

I just recall that our repository now is in https://github.com/mathworks/Emacs-MATLAB-Mode.git

And we have it also in MELPA. As we discussed I would like to have it in
ELPA (all authors signed the FSF papers). If it works as expected I
might remove it from MELPA.

The following two points are not entirely  clear to me:

    1. The version numbering and the commits we push.

       1. In MELPA every commit we push, will result in an updated MELPA
          version. There version scheme is like for example in our case.
           matlab-mode                    20241117.1628

       2. I see that ELPA has something like this
         aggressive-indent              1.10.0         available    gnu   
         aggressive-indent              20230112.1300  available    melpa 
        so is the GNU/EPLA version identical to the MELPA one

    2. The procedure for MELPA is as follows.

       1. MELPA itself dwells in github, so

       2. I need to fork that repository, clone it

       3. Add a branch,

       4. Add a recipe file that looks like
--8<---------------cut here---------------start------------->8---
(matlab-mode
 :fetcher github
 :repo "mathworks/Emacs-MATLAB-Mode"
 :files (:defaults
         ("toolbox" "toolbox/*.m")
         ("toolbox/+emacs" "toolbox/+emacs/*.m")
         ("toolbox/+emacs/@Breakpoints" "toolbox/+emacs/@Breakpoints/*.m")
         ("toolbox/+emacs/@EmacsServer" "toolbox/+emacs/@EmacsServer/*.m")
         ("toolbox/+emacs/@Stack" "toolbox/+emacs/@Stack/*.m")
         ("bin" "bin/*.sh")
         (:exclude "matlab-maint.el")))
--8<---------------cut here---------------end--------------->8---
        1. Commit and push

        2. Open a pull-request.

Now what is the procedure for ELPA, and is there anything like a recipe
file? 
Thanks and 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

[Philip Kaludercic]

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

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

> Hi
>
>
>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>> 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.
>
>
> Ok, we finished some weeks ago but also had to merge some branches with new features. 
>
> I just recall that our repository now is in https://github.com/mathworks/Emacs-MATLAB-Mode.git
>
> And we have it also in MELPA. As we discussed I would like to have it in
> ELPA (all authors signed the FSF papers). If it works as expected I
> might remove it from MELPA.
> The following two points are not entirely  clear to me:
>
>     1. The version numbering and the commits we push.
>
>        1. In MELPA every commit we push, will result in an updated MELPA
>           version. There version scheme is like for example in our case.
>            matlab-mode                    20241117.1628
>
>        2. I see that ELPA has something like this
>          aggressive-indent              1.10.0         available    gnu   
>          aggressive-indent              20230112.1300  available    melpa 
>         so is the GNU/EPLA version identical to the MELPA one
>
>     2. The procedure for MELPA is as follows.
>
>        1. MELPA itself dwells in github, so
>
>        2. I need to fork that repository, clone it
>
>        3. Add a branch,
>
>        4. Add a recipe file that looks like
>
> (matlab-mode
>  :fetcher github
>  :repo "mathworks/Emacs-MATLAB-Mode"
>  :files (:defaults
>          ("toolbox" "toolbox/*.m")
>          ("toolbox/+emacs" "toolbox/+emacs/*.m")
>          ("toolbox/+emacs/@Breakpoints" "toolbox/+emacs/@Breakpoints/*.m")
>          ("toolbox/+emacs/@EmacsServer" "toolbox/+emacs/@EmacsServer/*.m")
>          ("toolbox/+emacs/@Stack" "toolbox/+emacs/@Stack/*.m")
>          ("bin" "bin/*.sh")
>          (:exclude "matlab-maint.el")))
>
>         1. Commit and push
>
>         2. Open a pull-request.
>
> Now what is the procedure for ELPA, and is there anything like a recipe
> file? 

You don't have to do anything*, I just have to add a package
specification (similar to the "recipe file" for MELPA) to elpa.git.

* As soon as it works.  The main issues right now, are as you noticed
  that ELPA doesn't release a new tarball for every commit, but just
  when a new version is released.  We track this by checking for commits
  that bump the "Version" header in the main file (in your case
  matlab.el).  You currently don't have any version number, so the build
  fails.  I would suggest applying a change like this, if it doesn't
  break any assumptions you have regarding the minimal Emacs version:


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

diff --git a/matlab.el b/matlab.el
index 8ca0ee24a2..b82229a672 100644
--- a/matlab.el
+++ b/matlab.el
@@ -5,11 +5,7 @@
 ;; Maintainer: Eric M. Ludlam <eludlam@mathworks.com>
 ;; Created: 04 Jan 91
 ;; Keywords: MATLAB(R)
-;; Version:
-
-(defconst matlab-mode-version "5.0"
-  "Current version of MATLAB(R) mode.")
-
+;; Version: 5.0
 ;;
 ;; Copyright (C) 1997-2022 Eric M. Ludlam
 ;; Copyright (C) 1991-1997 Matthew R. Wette
@@ -50,6 +46,10 @@
 
 ;;; Code:
 
+(defconst matlab-mode-version (package-get-version)
+  "Current version of MATLAB(R) mode.")
+
+
 (require 'matlab-compat)
 (require 'matlab-syntax)
 (require 'matlab-scan)

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


  The other issue is that ELPA checks the copyright string and wants to
  see that all packages in GNU ELPA have their copyright assigned to the
  FSF.

  If you can fix these two things, then everything should go through.
  You can then decide to filter out files out of the final tarball by
  adding an .elpaignore file that lists what files to exclude.

> Thanks and regards
>
> Uwe Brauer 

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

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> +(defconst matlab-mode-version (package-get-version)
> +  "Current version of MATLAB(R) mode.")

We have tried to discourage the addition of such variables and commands,
given that one can always find that information by other means,
e.g. interactively with `describe-package` or from Lisp:

    (package-desc-version (cadr (assq 'foo package-alist)))

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

[Uwe Brauer via Matlab-emacs-discuss]

[-- Attachment #1.1: Type: text/plain, Size: 3011 bytes --]


> Uwe Brauer <oub-YB6e1s5WF/He5aOfsHch1g@public.gmane.org> writes:

> You don't have to do anything*, I just have to add a package
> specification (similar to the "recipe file" for MELPA) to elpa.git.

> * As soon as it works.  The main issues right now, are as you noticed
>   that ELPA doesn't release a new tarball for every commit, but just
>   when a new version is released.  We track this by checking for commits
>   that bump the "Version" header in the main file (in your case
>   matlab.el).  You currently don't have any version number, so the build
>   fails.  I would suggest applying a change like this, if it doesn't
>   break any assumptions you have regarding the minimal Emacs version:

> diff --git a/matlab.el b/matlab.el
> index 8ca0ee24a2..b82229a672 100644
> --- a/matlab.el
> +++ b/matlab.el
> @@ -5,11 +5,7 @@
>  ;; Maintainer: Eric M. Ludlam <eludlam-I5WecO5yM8GakBO8gow8eQ@public.gmane.org>
>  ;; Created: 04 Jan 91
>  ;; Keywords: MATLAB(R)
> -;; Version:
> -
> -(defconst matlab-mode-version "5.0"
> -  "Current version of MATLAB(R) mode.")
> -
> +;; Version: 5.0
>  ;;
>  ;; Copyright (C) 1997-2022 Eric M. Ludlam
>  ;; Copyright (C) 1991-1997 Matthew R. Wette
> @@ -50,6 +46,10 @@
 
>  ;;; Code:
 
> +(defconst matlab-mode-version (package-get-version)
> +  "Current version of MATLAB(R) mode.")
> +
> +
>  (require 'matlab-compat)
>  (require 'matlab-syntax)
>  (require 'matlab-scan)

A couple of remarks, 

    1. this diff seems against an older matlab-mode version (may the one
       in sourceforge), the latest github version is 6.2
       https://github.com/mathworks/Emacs-MATLAB-Mode.git

    2. Jonas Bernoulli one of the MELPA maintainers, recommended (but
       did not demand) to add file called matlab-mode.el which is
       basically a dummy file but also contains the current version 


>   The other issue is that ELPA checks the copyright string and wants to
>   see that all packages in GNU ELPA have their copyright assigned to the
>   FSF.

There is an automated process for checking this. If I had known, it
would have saved my quite a bit of time and work. I eyeballed the logs
and if there was an unknown author I checked the diff, and if necessary
contacted him. 

>   If you can fix these two things, then everything should go through.
>   You can then decide to filter out files out of the final tarball by
>   adding an .elpaignore file that lists what files to exclude.


    1. I will add an elpaignore file, which is urgent,

    2. And concerning the version number, what shall I do, your proposal
       or Stefan's?

For the moment being I would like to keep the MELPA version as well till
I know ELPA works

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 #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5684 bytes --]

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



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

_______________________________________________
Matlab-emacs-discuss mailing list
Matlab-emacs-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

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

[Uwe Brauer]

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

>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>> +(defconst matlab-mode-version (package-get-version)
>> +  "Current version of MATLAB(R) mode.")

> We have tried to discourage the addition of such variables and commands,
> given that one can always find that information by other means,
> e.g. interactively with `describe-package` or from Lisp:

>     (package-desc-version (cadr (assq 'foo package-alist)))

So you want me use just that string 
well (package-desc-version (cadr (assq 'matlab-mode package-alist)))
I presume 

in matlab.el (and matlab-mode.el)?

What's about our current setting 

(defconst matlab-mode-version "6.2"
  "Current version of MATLAB(R) mode.")

Which we need for MELPA? 

-- 
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, Re: having emacs-matlab in ELPA, finally. FSF paper signed

[Uwe Brauer]

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


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

 
> +(defconst matlab-mode-version (package-get-version)
> +  "Current version of MATLAB(R) mode.")
> +
> +
>  (require 'matlab-compat)
>  (require 'matlab-syntax)
>  (require 'matlab-scan)


>   The other issue is that ELPA checks the copyright string and wants to
>   see that all packages in GNU ELPA have their copyright assigned to the
>   FSF.

>   If you can fix these two things, then everything should go through.
>   You can then decide to filter out files out of the final tarball by
>   adding an .elpaignore file that lists what files to exclude.

I added .elpaignore, 
and pushed the commit to the github repository.

Concerning the version header, I got two different recommendation so I
prefer to wait till this is settled, and also what to do with the
original string that is needed for MELPA


> We have tried to discourage the addition of such variables and commands,
> given that one can always find that information by other means,
> e.g. interactively with `describe-package` or from Lisp:

>     (package-desc-version (cadr (assq 'foo package-alist)))

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

[Stefan Kangas]

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

>>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>> +(defconst matlab-mode-version (package-get-version)
>>> +  "Current version of MATLAB(R) mode.")
>
>> We have tried to discourage the addition of such variables and commands,
>> given that one can always find that information by other means,
>> e.g. interactively with `describe-package` or from Lisp:
>
>>     (package-desc-version (cadr (assq 'foo package-alist)))
>
> So you want me use just that string
> well (package-desc-version (cadr (assq 'matlab-mode package-alist)))
> I presume
>
> in matlab.el (and matlab-mode.el)?

That's what I would do, indeed.  Well, I'd use this if you need the
string form:

    (package-version-join
     (package-desc-version (cadr (assq 'matlab-mode package-alist))))

Yeah, it's a bit of a mouthful.  Most packages don't bother, and just
rely on `describe-package`, I think.

That said, there's nothing wrong with keeping it around; it just seems
redundant now that you have a "Version" header.  I mostly mentioned it
for the record, and in case you wanted to get rid of some possible
redundancy.

(Personally, I'm not sure if the `matlab-show-version` command is needed
either given that we have `describe-package`.  In emacs.git, we tend to
make such `foo-package-version` commands obsolete.)

> What's about our current setting
>
> (defconst matlab-mode-version "6.2"
>   "Current version of MATLAB(R) mode.")
>
> Which we need for MELPA?

Hmm, are you sure that you need it for MELPA even with the addition of
the "Version" header?

In any case, this is an extremely minor nit either way.

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

[Uwe Brauer]

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

>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>>>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:
>> 
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>> +(defconst matlab-mode-version (package-get-version)
>>> +  "Current version of MATLAB(R) mode.")
>> 
>>> We have tried to discourage the addition of such variables and commands,
>>> given that one can always find that information by other means,
>>> e.g. interactively with `describe-package` or from Lisp:
>> 
>>> (package-desc-version (cadr (assq 'foo package-alist)))
>> 
>> So you want me use just that string
>> well (package-desc-version (cadr (assq 'matlab-mode package-alist)))
>> I presume
>> 
>> in matlab.el (and matlab-mode.el)?

> That's what I would do, indeed.  Well, I'd use this if you need the
> string form:

>     (package-version-join
>      (package-desc-version (cadr (assq 'matlab-mode package-alist))))

Just to be sure, in both files, matlab.el and and matlab-mode.el?



>> What's about our current setting
>> 
>> (defconst matlab-mode-version "6.2"
>> "Current version of MATLAB(R) mode.")
>> 
>> Which we need for MELPA?

> Hmm, are you sure that you need it for MELPA even with the addition of
> the "Version" header?

> In any case, this is an extremely minor nit either way.


Ok, a last question then, as Philip wrote 

,----
| * As soon as it works.  The main issues right now, are as you noticed
|   that ELPA doesn't release a new tarball for every commit, but just
|   when a new version is released.  We track this by checking for commits
|   that bump the "Version" header in the main file (in your case
|   matlab.el).  You currently don't have any version number, so the build
|   fails.  I would suggest applying a change like this, if it doesn't
|   break any assumptions you have regarding the minimal Emacs version:
`----

But what is meant by «bump the Version header"
since this header somehow seems to be determined by 
     (package-version-join
      (package-desc-version (cadr (assq 'matlab-mode package-alist))))

But if I run eval-sexep this returns 
"20191223.2012"


So I don't see any place where I manually change the Version header. Or
are we talking about adding a (git) tag?

I guess I need something  like this (stolen from auctex, who BTW use 😉
,----
| (defconst AUCTeX-version (package-get-version)
|   "AUCTeX version.")
`----


;;; matlab.el --- major mode for MATLAB(R) dot-m files -*- lexical-binding: t -*-

;; Copyright (C) 2014-2024 Free Software Foundation, Inc.

;; Version: 6.2
;; URL: https://www.gnu.org/software/auctex/
;; Author: Matt Wette <mwette@alumni.caltech.edu>,
;;         Eric M. Ludlam <eludlam@mathworks.com>
;; Maintainer: Uwe Brauer <oub@mat.ucm.es>,
;;             Eric M. Ludlam  <eludlam@mathworks.com> 
;; Package-Requires: ((emacs "27.1"))
;; Created: 04 Jan 91
;; Keywords: MATLAB(R)


Uwe 

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

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

[Stefan Kangas]

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

> Just to be sure, in both files, matlab.el and and matlab-mode.el?

If the package is called `matlab-mode`, then here's the updated
definition that I would use in matlab-mode.el:

    (defconst matlab-mode-version
      (package-version-join
       (package-desc-version (cadr (assq 'matlab-mode package-alist))))
      "Current version of MATLAB(R) mode.")

In matlab-mode.el, you already have the version already in the form of
the version header, i.e. the line that reads:

    ;; Version: 6.2

This line does not need changing until you want to bump the version.

> But what is meant by «bump the Version header"

Every time you push a commit that updates the version header, that is
the above line in matlab-mode.el, with a higher version number, that
means that you "bump the version header".

The GNU ELPA scripts will then take that as an indication that it should
release a new version based on that commit, and do it.

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

[Uwe Brauer]

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

>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>> Just to be sure, in both files, matlab.el and and matlab-mode.el?

> If the package is called `matlab-mode`, then here's the updated
> definition that I would use in matlab-mode.el:

>     (defconst matlab-mode-version
>       (package-version-join
>        (package-desc-version (cadr (assq 'matlab-mode package-alist))))
>       "Current version of MATLAB(R) mode.")

> In matlab-mode.el, you already have the version already in the form of
> the version header, i.e. the line that reads:

>     ;; Version: 6.2

> This line does not need changing until you want to bump the version.

>> But what is meant by «bump the Version header"

> Every time you push a commit that updates the version header, that is
> the above line in matlab-mode.el, with a higher version number, that
> means that you "bump the version header".


Ok, last nitpicking question, right now the header reads


;; Copyright (C) 1997-2024 Eric M. Ludlam
;; Copyright (C) 1991-1997 Matthew R. Wette

All authors/contributers signed the FSF paper, the last one in January
2024, 

So should I replace that by

;; Copyright (C) 1991-2024 Free Software Foundation, Inc.

And delete the other authors? or shall I just use the year 2024? because it was
the year the last remaining contributor signed?


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

Stefan Kangas <stefankangas@gmail.com> writes:

> Uwe Brauer <oub@mat.ucm.es> writes:
>
>>>>> "SK" == Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>> +(defconst matlab-mode-version (package-get-version)
>>>> +  "Current version of MATLAB(R) mode.")
>>
>>> We have tried to discourage the addition of such variables and commands,
>>> given that one can always find that information by other means,
>>> e.g. interactively with `describe-package` or from Lisp:
>>
>>>     (package-desc-version (cadr (assq 'foo package-alist)))
>>
>> So you want me use just that string
>> well (package-desc-version (cadr (assq 'matlab-mode package-alist)))
>> I presume
>>
>> in matlab.el (and matlab-mode.el)?
>
> That's what I would do, indeed.  Well, I'd use this if you need the
> string form:
>
>     (package-version-join
>      (package-desc-version (cadr (assq 'matlab-mode package-alist))))

We should keep in mind that this will break if the package is not
installed using package.el, as then

  (cadr (assq 'matlab-mode package-alist)) ;=> nil

and thus

  (package-desc-version nil) ;!> (wrong-type-argument package-desc nil)

> Yeah, it's a bit of a mouthful.  Most packages don't bother, and just
> rely on `describe-package`, I think.
>
> That said, there's nothing wrong with keeping it around; it just seems
> redundant now that you have a "Version" header.  I mostly mentioned it
> for the record, and in case you wanted to get rid of some possible
> redundancy.
>
> (Personally, I'm not sure if the `matlab-show-version` command is needed
> either given that we have `describe-package`.  In emacs.git, we tend to
> make such `foo-package-version` commands obsolete.)

1+ to this.  The custom commands for version numbers are an anti-pattern IMO.

>
>> What's about our current setting
>>
>> (defconst matlab-mode-version "6.2"
>>   "Current version of MATLAB(R) mode.")
>>
>> Which we need for MELPA?
>
> Hmm, are you sure that you need it for MELPA even with the addition of
> the "Version" header?
>
> In any case, this is an extremely minor nit either way.

Uwe Brauer via Matlab-emacs-discuss
<matlab-emacs-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
writes:

>> Uwe Brauer <oub-YB6e1s5WF/He5aOfsHch1g@public.gmane.org> writes:
>
>> You don't have to do anything*, I just have to add a package
>> specification (similar to the "recipe file" for MELPA) to elpa.git.
>
>> * As soon as it works.  The main issues right now, are as you noticed
>>   that ELPA doesn't release a new tarball for every commit, but just
>>   when a new version is released.  We track this by checking for commits
>>   that bump the "Version" header in the main file (in your case
>>   matlab.el).  You currently don't have any version number, so the build
>>   fails.  I would suggest applying a change like this, if it doesn't
>>   break any assumptions you have regarding the minimal Emacs version:
>
>> diff --git a/matlab.el b/matlab.el
>> index 8ca0ee24a2..b82229a672 100644
>> --- a/matlab.el
>> +++ b/matlab.el
>> @@ -5,11 +5,7 @@
>>  ;; Maintainer: Eric M. Ludlam <eludlam-I5WecO5yM8GakBO8gow8eQ@public.gmane.org>
>>  ;; Created: 04 Jan 91
>>  ;; Keywords: MATLAB(R)
>> -;; Version:
>> -
>> -(defconst matlab-mode-version "5.0"
>> -  "Current version of MATLAB(R) mode.")
>> -
>> +;; Version: 5.0
>>  ;;
>>  ;; Copyright (C) 1997-2022 Eric M. Ludlam
>>  ;; Copyright (C) 1991-1997 Matthew R. Wette
>> @@ -50,6 +46,10 @@
>  
>>  ;;; Code:
>  
>> +(defconst matlab-mode-version (package-get-version)
>> +  "Current version of MATLAB(R) mode.")
>> +
>> +
>>  (require 'matlab-compat)
>>  (require 'matlab-syntax)
>>  (require 'matlab-scan)
>
> A couple of remarks, 
>
>     1. this diff seems against an older matlab-mode version (may the one
>        in sourceforge), the latest github version is 6.2
>        https://github.com/mathworks/Emacs-MATLAB-Mode.git

That might very well be, I used a local checkout that ELPA made when
experimenting with the package, and it appears that was not the newest
version.

>     2. Jonas Bernoulli one of the MELPA maintainers, recommended (but
>        did not demand) to add file called matlab-mode.el which is
>        basically a dummy file but also contains the current version 

What is the name of the MELPA package?  If it is called "matlab", then
by default ELPA will consult the "matlab.el" file for version
information.  Otherwise it will consult "matlab-mode.el".  We can adjust
this though if need be in the package specification.

>>   The other issue is that ELPA checks the copyright string and wants to
>>   see that all packages in GNU ELPA have their copyright assigned to the
>>   FSF.
>
> There is an automated process for checking this. If I had known, it
> would have saved my quite a bit of time and work. I eyeballed the logs
> and if there was an unknown author I checked the diff, and if necessary
> contacted him. 

It doesn't go through the logs, it just searches for a copyright string
somewhere in the header.

>>   If you can fix these two things, then everything should go through.
>>   You can then decide to filter out files out of the final tarball by
>>   adding an .elpaignore file that lists what files to exclude.
>
>
>     1. I will add an elpaignore file, which is urgent,
>
>     2. And concerning the version number, what shall I do, your proposal
>        or Stefan's?
>
> For the moment being I would like to keep the MELPA version as well till
> I know ELPA works

Inherently there is no reason against having both, especially if people
have already installed the package via MELPA.

> Uwe 

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

>> Uwe Brauer <oub@mat.ucm.es> writes:
>
>  
>> +(defconst matlab-mode-version (package-get-version)
>> +  "Current version of MATLAB(R) mode.")
>> +
>> +
>>  (require 'matlab-compat)
>>  (require 'matlab-syntax)
>>  (require 'matlab-scan)
>
>
>>   The other issue is that ELPA checks the copyright string and wants to
>>   see that all packages in GNU ELPA have their copyright assigned to the
>>   FSF.
>
>>   If you can fix these two things, then everything should go through.
>>   You can then decide to filter out files out of the final tarball by
>>   adding an .elpaignore file that lists what files to exclude.
>
> I added .elpaignore, 
> and pushed the commit to the github repository.

1+

> Concerning the version header, I got two different recommendation so I
> prefer to wait till this is settled, and also what to do with the
> original string that is needed for MELPA
>
>
>> We have tried to discourage the addition of such variables and commands,
>> given that one can always find that information by other means,
>> e.g. interactively with `describe-package` or from Lisp:
>
>>     (package-desc-version (cadr (assq 'foo package-alist)))

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

[Uwe Brauer]

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


> Stefan Kangas <stefankangas@gmail.com> writes:

> We should keep in mind that this will break if the package is not
> installed using package.el, as then

>   (cadr (assq 'matlab-mode package-alist)) ;=> nil

> and thus

>   (package-desc-version nil) ;!> (wrong-type-argument package-desc nil)


> 1+ to this.  The custom commands for version numbers are an anti-pattern IMO.

Ok I leave it to you two to sort this out, I do whatever the consensus is.


> Uwe Brauer via Matlab-emacs-discuss
> <matlab-emacs-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> writes:


> That might very well be, I used a local checkout that ELPA made when
> experimenting with the package, and it appears that was not the newest
> version.


> What is the name of the MELPA package?  If it is called "matlab", then
> by default ELPA will consult the "matlab.el" file for version
> information.  Otherwise it will consult "matlab-mode.el".  We can adjust
> this though if need be in the package specification.

It is called now matlab-mode!

> It doesn't go through the logs, it just searches for a copyright string
> somewhere in the header.
But in header just in matlab-mode.el or in all files?
I repeat the question I asked Stefan

Ok, last nitpicking question, right now the header reads


;; Copyright (C) 1997-2024 Eric M. Ludlam
;; Copyright (C) 1991-1997 Matthew R. Wette

All authors/contributers signed the FSF paper, the last one in January
2024, 

So should I replace that by

;; Copyright (C) 1991-2024 Free Software Foundation, Inc.

And delete the other authors? or shall I just use the year 2024? because it was
the year the last remaining contributor signed?

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

[Philip Kaludercic]

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

>> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> We should keep in mind that this will break if the package is not
>> installed using package.el, as then
>
>>   (cadr (assq 'matlab-mode package-alist)) ;=> nil
>
>> and thus
>
>>   (package-desc-version nil) ;!> (wrong-type-argument package-desc nil)
>
>
>> 1+ to this.  The custom commands for version numbers are an anti-pattern IMO.
>
> Ok I leave it to you two to sort this out, I do whatever the consensus is.

I vote for no custom version command.

>
>> Uwe Brauer via Matlab-emacs-discuss
>> <matlab-emacs-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>> writes:
>
>
>> That might very well be, I used a local checkout that ELPA made when
>> experimenting with the package, and it appears that was not the newest
>> version.
>
>
>> What is the name of the MELPA package?  If it is called "matlab", then
>> by default ELPA will consult the "matlab.el" file for version
>> information.  Otherwise it will consult "matlab-mode.el".  We can adjust
>> this though if need be in the package specification.
>
> It is called now matlab-mode!

OK.  So do you want to track the version number in matlab.el or
matlab-mode.el?

>> It doesn't go through the logs, it just searches for a copyright string
>> somewhere in the header.
> But in header just in matlab-mode.el or in all files?
> I repeat the question I asked Stefan
>
> Ok, last nitpicking question, right now the header reads
>
>
> ;; Copyright (C) 1997-2024 Eric M. Ludlam
> ;; Copyright (C) 1991-1997 Matthew R. Wette
>
> All authors/contributers signed the FSF paper, the last one in January
> 2024, 
>
> So should I replace that by
>
> ;; Copyright (C) 1991-2024 Free Software Foundation, Inc.
>
> And delete the other authors? or shall I just use the year 2024? because it was
> the year the last remaining contributor signed?

IANAL, but I think that should work.

> Uwe 

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

[Uwe Brauer via Emacs development discussions.]

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


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

> I vote for no custom version command.
ok

> OK.  So do you want to track the version number in matlab.el or
> matlab-mode.el?

 matlab-mode.el
> IANAL, but I think that should work.

Ok I change the header just in matlab.el and matlab-mode.el



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

[Uwe Brauer via Emacs development discussions.]

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


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

> I vote for no custom version command.

Ok I just realized, if I put in matlab-mode.el

(defconst matlab-mode-version (package-get-version)
  "Current version of MATLAB(R) mode.")
For the ELPA users

Can I leave 
(defconst matlab-mode-version "6.2"
  "Current version of MATLAB(R) mode.")

In matlab.el for the MELPA users?





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