adding smalltalk-mode to ELPA?

Dear list,

GNU smalltalk has a official smalltalk-mode for emacs. Nowdays the
standard to distribute emacs packages is via ELPA or MELPA; since GNU
smalltalk is already a GNU project, maybe the smalltalk-mode should be
packaged and distributed on GNU ELPA?

Derek

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 27 Feb 2019 10:05:45 +0800 Derek wrote:
> maybe the smalltalk-mode should be
> packaged and distributed on GNU ELPA?

maybe, but that would be a question for GNU ELPA to decide

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

bill-auger writes:

> On Wed, 27 Feb 2019 10:05:45 +0800 Derek wrote:
>> maybe the smalltalk-mode should be
>> packaged and distributed on GNU ELPA?
>
> maybe, but that would be a question for GNU ELPA to decide
>
I think they welcome anything copyrighted by FSF already?
For non-FSF copyrighted stuff, there is also MELPA


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 27 Feb 2019 23:52:07 +0800 Derek wrote:
> I think they welcome anything copyrighted by FSF already?

i dont know what they welcome or un-welcome - that is yet another
question better posed toward those "they"

generally speaking, software developers do not package their software -
it is those who maintain package repos who decide what gets packaged
and who packages it

most often, the original software developers are not consulted about
packaging, nor even be aware that any packaging has been done, nor by
whom, nor where it is hosted

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On February 28, 2019 2:45:51 AM GMT+08:00, bill-auger <[hidden email]> wrote:
>On Wed, 27 Feb 2019 23:52:07 +0800 Derek wrote:
>> I think they welcome anything copyrighted by FSF already?
>
>i dont know what they welcome or un-welcome - that is yet another
>question better posed toward those "they"
>
>generally speaking, software developers do not package their software -
>it is those who maintain package repos who decide what gets packaged
>and who packages it
ELPA is not like a linux distibution such as debian. it is more like cpan, everything that is qualified is welcome, but you has to ask and prepare your own package. their website has instruction on how to apply., which is basically sending the script and an email.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Wilfred,

I read the git log in the smalltalk repo, and the last few changes to
smalltalk-mode are all done by you. I am assuming you are the principal
maintainer of smalltalk-mode. I asked the question on the list last
month but got very few responses. Do you want to add smalltalk-mode to
ELPA? Can I do anything to help?

Sorry for replying to myself. I think smalltalk-mode is useful even where
smalltalk cannot run yet; for example on a phone.

Derek


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Derek Zhou wrote:
> Wilfred,
> Do you want to add smalltalk-mode to ELPA?

the answer i gave you is probably the best one that anyone could give -
maybe i could have been more clear

generally speaking, software developers do not package their software -
that is almost always done by someone who is not a member of the
upstream project dev team - it is usually done by a member of the team
that maintains their respective package repo - in this case, you noted
yourself that they accept anonymous contributions via email - nothing
else is required of the upstream dev team for this to happen

GNU smalltalk is free software; which means that you can use it for any
purpose as you like, including packaging it for re-distribution - you do
not need to ask anyone for permission - it would be of no consequence if
Wlifred or anyone else explicitly asked you not to package it, you would
still be fully permitted to do so by the GPL license, simply because you
have a copy

i think the question you are really asking here is: "does someone on the
GNU smalltalk dev team plan on packaging it themselves?" - to answer
that question, i would say again that the answer is most likely: "no" -
i think it would have already been in that repo, many years ago, if that
was a goal of the team

however, its absence would not imply that the authors are against the
idea - i expect that it would be a welcome contribution, if someone
takes the time to package it, and if the repo maintainers find it useful
enough to include - packaging is simply a task that upstream developers
generally do not do themselves; but some user like yourself, very well
could do it, and that is usually how it happens


Derek Zhou wrote:
> Can I do anything to help?

just do it - the ELPA team are the appropriate people to ask these
questions - there really is nothing the upstream can or should do about
such a request - its not their domain - the only important question is
whether or not the ELPA team will accept it, or you assist in packaging it

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

bill-auger writes:

Like I said before, ELPA is more like CPAN instead of Debian. With CPAN,
the authors put their perl modules up, not the other way around. It is a
sharing place for authors; not a distribution. they do reserve right to
refuse something they deem inappropriate, that's all. Of cause it is
entirely possible that a third party can do the posting, and I could do
it, but I do want to get the author's blessing first.

Anyway, if no objection received before the weekend, I will do it next
week.

Derek

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Derek Zhou wrote:
> but I do want to get the author's blessing first.

you already have the authors blessing - the GPL license *is* the authors
blessing - really - it is a beautiful thing in that way :)

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Hi,

Derek Zhou kindly contacted us to add smalltalk-mode to GNU ELPA, so
I looked at the archives of this mailing-list to figure out exactly what
was the underlying intention, and I think there was a slight
misunderstanding, so I'm not sure what to do and I need your help.

GNU ELPA is a part of the Emacs project and it has two faces:

- the elpa.gnu.org website used to publish&distribute Elisp packages
  using the ELPA protocol (so the packages can be conveniently installed
  and upgraded from within Emacs).

- the elpa.git repository where the source of the packages are kept and
  from which we prepare the release packages that are distributed on
  elpa.gnu.org.

Many GNU ELPA packages *live* in elpa.git, while many others have an
official upstream elsewhere (Gitlab, Github, younameit) and the
package's maintainers keep them in sync regularly.
[ And a few more are in the sad state of being stale w.r.t an upstream
  version, typically for lack of interest and/or copyright paperwork.  ]

We'd be happy to add smalltalk-mode to elpa.git, but we wouldn't want
this to end up being a fork or becoming some stale copy of your own
smalltalk-mode.el, which is why I came here to figure out whether there
is a firm commitment here to keep the two copies in sync.  The easiest
way to "keep them in sync" would be to *move* smalltalk-mode.el to
elpa.git (i.e. not keep it in the smalltalk.git repository any more),
but I haven't seen any sign that this was the intention so far.

If smalltalk-mode.el lives in both repositories, keeping them in sync
will be more work than for the regular Elisp package that lives both in
elpa.git and in Gitlab because the elpa.git version will not want to
come with the other files included in smalltalk.git, and two-way
synchronization between two such parallel branches is a lot more painful
than just `git merge`.

An intermediate option might be to split smalltalk-mode.el out of your
`master` branch and into a separate branch: then we can sync that branch
with that of elpa.git conveniently with `git merge` (and if needed you
can still include smalltalk-mode.el into your release tarball as well
as include it indirectly in `master` via git submodules).

In any case, it's for you Smalltalk devs to decide.


        Stefan

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Stefan Monnier writes:
>
> We'd be happy to add smalltalk-mode to elpa.git, but we wouldn't want
> this to end up being a fork or becoming some stale copy of your own
> smalltalk-mode.el, which is why I came here to figure out whether there
> is a firm commitment here to keep the two copies in sync.  The easiest
> way to "keep them in sync" would be to *move* smalltalk-mode.el to
> elpa.git (i.e. not keep it in the smalltalk.git repository any more),
> but I haven't seen any sign that this was the intention so far.
>
IMHO a fork is not necessarily a bad thing here. GNU Smalltalk is mature
software; the smalltalk-mode included is compatible with emacs as far
back as 21 and Xemacs, whereas ELPA is only targeted for modern emacs
like 24 and up. Also it is one file of only a few thousand lines and not
likely to grow much bigger. Judged by the rate of changes for the last
few years even elisp newbie like me can keep them in sync, and I do plan
to do that if no one better than me claim the job.

Derek

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

the emacs mode is in the smalltalk source tree because it is distributed
and installed with the smalltalk software, so that all users of the
smalltalk software will have, it without the need for installing a
separate package or package manager - for that reason there is little
need to package it elsewhere - from what i understand, derek was
proposing that this would be useful for people who are reading
gnu-smalltalk code, but for some reason do not have smalltalk actually
installed - IMHO that use-case is minuscule at most; but anyone is
welcome to package it, of course if this is seen as useful - i
will contend once again, that there is nothing for the upstream
developers to do toward that end - to expect the upstream developers to
manage or even to assist with packaging, is a very unconventional
inversion of responsibility

generally speaking, the upstream software developers do not engage in
the packaging of their own software - even if they wanted to, there are
simply too many package managers to package for - if the software gets
packaged at all, that is usually done by someone else who is not
associated with the upstream dev team, but someone who is associated
with the repository for that particular package manager, or one of it's
users

whenever the package gets out of sync with the upstream, it is the
packager's responsibility to attend to that - i have never seen any
upstream be asked to maintain repo packages themselves, nor to
re-organize their source tree to provide an "intermediate option" that
makes packaging easier for the packager - the upstream publishes
tarballs - packaging is not their domain - maintaining repo packages is
entirely to responsibility of the packager, regardless of how simple or
difficult that particular software is to package - the human person who
maintains the repo package *is* precisely that "intermediate option" -
that is entirely what a repo package maintainer does - they fit the
upstream sources (whatever form they take) into a their particular
packaging format (whatever form that takes)

in this case, i think this is literally a single file - the humble
`curl` command is sufficient for pulling in the latest version - i will
also add that if you insist on mirroring the software in git, but for
some reason you only want to mirror a subset of the upstream tree, the
git filter-branch feature exists for that purpose - there is still
nothing that the upstream maintainers need to do in order to
accommodate that

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

bill-auger <[hidden email]> writes:
> the emacs mode is in the smalltalk source tree because it is distributed
> and installed with the smalltalk software, so that all users of the
> smalltalk software will have, it without the need for installing a
> separate package or package manager - for that reason there is little
> need to package it elsewhere

AFAICT as it currently stands, installing GNU Smalltalk will indeed
install a copy of smalltalk-mode.el (and smalltalk-mode-init.el)
somewhere, but the user will still have to manually load that file
(typically from the ~/.emacs after reading some README to figure out
exactly what to put in there).  In contrast a package installed via ELPA
will automatically be activated so the user will have smalltalk-mode
enabled in *.st files without needing any extra steps.  Of course the
`M-x package-install` is itself an extra step (tho there's been
discussions to try and eliminate this and pre-enable some ELPA packages,
so that for example opening a *.st file would suggest to the user to
install smalltalk-mode if not done yet).

So there is some extra convenience there for users.

For the developer, there can also be some benefits in that it's much
easier to use other packages in your own package (because you don't need
to tell your users to install that other package and/or handle the case
where that other package is not available: you just add it as
a dependency).  But I don't think smalltalk-mode maintainers would
benefit much from this.

> from what i understand, derek was proposing that this would be useful
> for people who are reading gnu-smalltalk code, but for some reason do
> not have smalltalk actually installed - IMHO that use-case is
> minuscule at most;

That use-case seems minor, indeed.  Maybe there can be other use-cases
for people using some other Smalltalk system, tho IIUC other Smalltalk
systems don't keep their code in files that you could conveniently edit
with Emacs anyway.

> generally speaking, the upstream software developers do not engage in
> the packaging of their own software - even if they wanted to, there are
> simply too many package managers to package for - if the software gets
> packaged at all, that is usually done by someone else who is not
> associated with the upstream dev team, but someone who is associated
> with the repository for that particular package manager, or one of it's
> users

elpa.git is not a "packaging solution".  It's a Git repository that is
meant to be used for development and also happens to have packages
automatically built from it, but most of the work of packaging is
delegated to the maintainer because there is "packager" as such.

> in this case, i think this is literally a single file - the humble
> `curl` command is sufficient for pulling in the latest version - i will

That won't preserve the Git history, so I was thinking more of a `git
filter-branch`.  Also, some Emacs developers will occasionally install
patches into the elpa.git side (e.g. to fix incompatibilities with newer
Emacs features, or clean up compiler warnings, ...), so the sync needs
to be 2-way.

Anyway, from what I understand, you have no intention of moving
smalltalk-mode.el elsewhere nor to spend your time with a 2-way sync.
In that case, I think it's best not to add smalltalk-mode.el to GNU ELPA
to avoid the risk of a fork.


        Stefan

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Tue, 26 Mar 2019 12:51:34 -0400 Stefan wrote:
> Anyway, from what I understand, you have no intention of moving
> smalltalk-mode.el elsewhere nor to spend your time with a 2-way sync.
> In that case, I think it's best not to add smalltalk-mode.el to GNU
> ELPA to avoid the risk of a fork.

i am not a member of the smalltalk dev team, they are listed on
savannah[1] - i was only offering some general observations,
anticipating what i would expect to be the response of most upstreams
when asked to to do the things you are suggesting

regarding the risk of maintaining a "stale" fork, i will say again that
is the entirely responsibility of the person who maintains that fork,
not the upstream - the states of downstream forks are simply
uninteresting to the upstream - if the packager attends to the package
diligently, then it will not go stale - in this particular case, i
think the packager would find that the smalltalk emacs mode was
probably complete 10-15 years ago - i would presume there is little
chance of a fork falling out-of-sync, even if the packager completely
ignores it, simply because the file is not likely to ever need changing


[1]: https://savannah.gnu.org/project/memberlist.php?group=smalltalk

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

I am currently not a GNU Emacs user and as a result have been quiet on
this topic.

There seems to be benefit[1] to move the smalltalk-model.el into the GNU
ELPA repository. I can check what rms wrote but I need one of you to do
the actual move.

holger


[1] It seems easier to enable the mode. It increases the visibility of
GNU Smalltalk and Smalltalk in general to emacs users.

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Holger Freyther writes:
Thanks Holger.

There are 2 ways we can do this:

1, keep the current smalltalk-mode.el in smalltalk git as is, for people
still using emacs 23 and before; fork smalltalk-mode.el to ELPA for
modern emacen. Occasionally back port bug fixes.

2, remove smalltalk-mode.el altogether from smalltalk git and encourage
people to use ELPA.

I'd suggest to do 1 first, at least until the next stable release of
gst. I use smalltalk and emacs daily, although still very green with
elisp programming, I can maintain smalltalk-mode on ELPA and do the 2
way sync required. Shouldn't take much time anyway.

Derek

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, 27 Mar 2019 09:05:20 +0800 Derek wrote:
> I can maintain smalltalk-mode on ELPA and do the 2
> way sync required.

i am still completely baffled about this fixation in having the
upstream's approval, cooperation, or involvement in the packaging
process - you have everything you could possibly need to do this on
your own - no explicit permission nor assistance is required

it is irrelevant where, or in what form the upstream publishes the code
that you are interested in - as the downstream packager, you simply
watch the upstream for changes, then pull in the changes and rebuild
the package at your leisure - how that gets done precisely, is a
peculiar combination of the form in which the upstream publishes its
code, and the quirks of the requirements/protocols of the target
packaging format and repo admins - it is entirely the task of the
packager to make that happen, by whatever means necessary - there is no
need for the upstream to be involved in that process nor even be aware
that it happened

what has me particularly perplexed, is the: "two-way sync required" -
developers and packagers are in an "upstream/downstream" relationship -
that very terminology indicates a one-way flow of information -
anything flowing back upstream, does so in the form of patches - even if
those patches are in the form of a git commit and a webby "pull
request", that is not the philosophical equivalent of a two-way sync -
maybe this is just a confusion of words - i assume what you meant by
that, is that you would keep a mirror in sync; but to be clear, that is
a one-way, passive operation

it sounds like what you are asking, is for the upstream to maintain the
packaging repo for you; which would be very unconventional - you may as
well ask them to additionally maintain yet another packaging repo for
debian, another for fedora, another for arch, and so on; but debian,
fedora, and arch do not expect upstreams to do that - upstreams are not
expected to cater to the quirks of any specific package managers -
upstreams publish tarballs, period - the debian packager maintains the
debian packaging repo (in whatever way is appropriate for debian), the
arch packager maintains the arch packaging repo (in whatever way is
appropriate for arch), and as well, the ELPA packager should maintain
the ELPA packaging repo (in whatever way is appropriate for ELPA)

even if full automation is desired, `curl` or `git filter-branch` and 5
minutes per year are all that anyone would need to maintain a package
for this - i just do not understand the presumption that the upstream
should need to do anything at all to assist with that

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

bill-auger <[hidden email]> writes:
> what has me particularly perplexed, is the: "two-way sync required" -
> developers and packagers are in an "upstream/downstream" relationship

That's because you still haven't understood that GNU ELPA is not just
a package distribution system.

The overall ELPA system is (it defines a format for repositories,
includes the package.el client to list/install/upgrade packages, and
includes various repositories, including MELPA and GNU ELPA).

But the GNU ELPA repository specifically isn't.

> it sounds like what you are asking, is for the upstream to maintain the
> packaging repo for you; which would be very unconventional -

Actually, it's the norm when it comes to Elisp packages (both for GNU
ELPA and for MELPA packages).


        Stefan

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk