Add to NonGNU ELPA #389
Comments
|
Although I'm not necessarily opposed to doing this, ever, I'm reluctant. I'm concerned that it might be "dishonest" --- create an expectation that I'm unable or unwilling to fulfill. The status quo:
That is the level of care and responsibility that I have time to aim for, currently. As a result, I could add a "stable" release tag to some commit, from time to time. Call it "version 1.42". But honestly it would still mean "unstable" MELPA's "version date-and-time", or "version commit digest" -- the status quo, masquerading as something else. I would not want to do this, for you, and discover I have created some expectation that I'm unwilling or unable to satisfy, for other people. Having said all that, I'll mull this over. Meanwhile you could install only Racket Mode from "unstable" MELPA. Of course I understand you might not want to do that, I just want to make sure you knew about that option. |
|
According to my totally scientific and unbiased Google search, users seem to view a MELPA stable tag like a GitHub release tag, which is as you just described. I use GitHub release tags to keep track of project state at major events like release announcements and conference talks. In any case, if you start a backlog specifically for improving the existing code base -- tests, docs, whatever -- I would totally grind on those tickets in my spare time. |
|
As long as there are plans to add a tag sometime in the future, I am satisfied. I've just run into too many projects that just forgot about it.
Yeah, I know about that possibility -- I've tried it but it never worked out the way I wanted it to. If I really needed it, I could also just clone the repo. |
|
@dedbox If that's the expectation, I'd feel better. @phikal I think where this trips me up is, I already use my best effort to make sure And for example, when I was working on the step-debugger feature, it was on a topic branch for some weeks or months. Not iterating on So if you ask me today, is HEAD stable, right now? I'd say, yes, to the best of my knowledge. And I use Racket Mode myself nearly every day, so many of its features get pretty heavily dog-fooded. But I don't know what I don't know. And with Emacs, people can be using many different mixes of modes that I do not personally dog-food. So, I'm aware it is a pretty big set of don't-knows. |
|
On Wed, Jul 10, 2019, 10:07 AM Greg Hendershott ***@***.***> wrote:
But I don't know what I don't know. And with Emacs, people can be using
many different mixes of modes that I do *not* personally dog-food. So,
I'm aware it is a pretty big set of don't-knows.
By this standard, would MELPA stable be empty?
|
|
Sorry if that sounded cheeky. I'm genuinely curious, but that's not so
relevant.
More directly, it sounds like you're setting an impossibly high standard
for an ecosystem as messy as Emacs'. Is there a better way to increase the
user base to surface cross-compatibility issues?
Eric
…On Wed, Jul 10, 2019, 10:28 AM Eric Griffis ***@***.***> wrote:
On Wed, Jul 10, 2019, 10:07 AM Greg Hendershott ***@***.***>
wrote:
> But I don't know what I don't know. And with Emacs, people can be using
> many different mixes of modes that I do *not* personally dog-food. So,
> I'm aware it is a pretty big set of don't-knows.
>
By this standard, would MELPA stable be empty?
|
|
And on second thought, another way of looking at it is that you've done
your due diligence in MELPA unstable (and then some), and maybe it's time
to take the leap because the release process and code base are stable
enough.
Of course, that's a big subjective 'maybe', because even a quality product
release would entail some amount of prep and follow-up that perhaps only
you could do at this point.
…On Wed, Jul 10, 2019, 10:52 AM Eric Griffis ***@***.***> wrote:
Sorry if that sounded cheeky. I'm genuinely curious, but that's not so
relevant.
More directly, it sounds like you're setting an impossibly high standard
for an ecosystem as messy as Emacs'. Is there a better way to increase the
user base to surface cross-compatibility issues?
Eric
On Wed, Jul 10, 2019, 10:28 AM Eric Griffis ***@***.***> wrote:
>
>
> On Wed, Jul 10, 2019, 10:07 AM Greg Hendershott ***@***.***>
> wrote:
>
>> But I don't know what I don't know. And with Emacs, people can be using
>> many different mixes of modes that I do *not* personally dog-food. So,
>> I'm aware it is a pretty big set of don't-knows.
>>
>
> By this standard, would MELPA stable be empty?
>
>
|
|
Just to touch base, I haven't forgotten about this, I've just been busy and keep deferring it. Realistically it will be at least another week or two until I can look at it again. |
|
I'd like to bring up the issue again, but this time not from the perspective of MELPA Stable but NonGNU ELPA, the new archive for packages without copyright assignments to the FSF. It will be enabled OOTB from Emacs 28 onwards, meaning that any package in NonGNU ELPA can be installed without any further configuration. Compared to MELPA, NonGNU distributes "stable" or "tagged" releases by default. The ELPA build system doesn't determine these by checking for the most recent Git tag, but by finds the last commit that bumps the version attribute in the package header. If there is any interest in adding racket-mode to NonGNU ELPA, all that has to be done is to add such a version tag (which also has the advantage that users can manually download and install the package via |
|
Thank you for following up. Racket Mode still has the same "rolling release" model I described above. I have no extra steps to make a "release" that is "more stable" than any other commit on the main branch. As a result:
If someone prefers stable releases to rolling releases: I understand, empathize, and respect that. I just don't have stable releases to offer. If someone is fine with rolling releases but prefers to use NonGNU ELPA instead of plain MELPA: Although I appreciate they have a preference unfortunately I'm not willing or able to accommodate it. |
I think that sounded kind of dogmatic. Let's say I create some automated process that runs every 3 months. It goes into the repo, and regardless of whatever the latest commit is, bumps the version string in So it's easy for me. And it's on NonGNU ELPA. And everyone is happy. Right? Really??
I just don't understand how my reality of rolling releases, would map onto the (entirely reasonable) expectations of people who expect stable releases to be.... stable releases, including all the associated perceived benefits. |
|
You may be interested in this thread. The current proposal is to extend ELPA by a option to have "rolling release" packages (i.e. like the devel archive), if packages like yours use this development model. As you have already said that you do your best to keep the master branch stable, I think that this would be a good compromise, do you agree? |
|
Thank you for following up.
I don't understand how that works, so a dumb question: Would this mean I wouldn't even need to add artificial, periodic "Just bumping the 'version' in racket-mode.el" commits? If so that sounds better than a good compromise, it sounds perfect. Otherwise I'd like to learn more. (Either way, I appreciate the user-expectations discussion elsewhere in that thread, that's helpful!) |
|
Greg Hendershott ***@***.***> writes:
Thank you for following up.
> We could add to elpa-admin.el some flag that makes it behave the same
> for the -devel and the non-devel repositories
I don't understand how that works, so a dumb question:
Would this mean I wouldn't even need to add artificial, periodic "Just
bumping the 'version' in racket-mode.el" commits?
Yes.
If so that sounds better than a good compromise, it sounds perfect.
Ok, I will see what can be done.
Otherwise I'd like to learn more.
(Either way, I appreciate the user-expectations discussion elsewhere
in that thread, that's helpful!)
I might have missed that, what are you referring to?
…--
Philip Kaludercic
|
Thank you!
Probably "discussion" over-states it; I just meant: https://mail.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg01818.html Remember, my whole introduction to NonGNU ELPA is via this issue, titled "Adding a Stable Tag". Plus the NonGNU ELPA web site packages mostly do have "stable"-like version numbers. Plus the web site doesn't talk about "stable" vs. "rolling" --- is it silent because "stable" is assumed as the obvious right thing, or, because it's not trying to take a position either way? It helped to see Stefan Kangas say it's the latter. Even if that's just the opinion of one maintainer and not "official GNU policy", it's more than nothing; it's some indication. Combine that with:
And it sounds encouraging, especially with the final item. |
|
After an inanpropriate delay, support for rolling release packages has been added to {NonGNU,GNU} ELPA. If you are still interested, we can progress with adding racket-mode to NonGNU ELPA. |
|
Thanks for following up. A few questions:
|
|
Two tiny questions/concerns:
|
|
Greg Hendershott ***@***.***> writes:
Thanks for following up.
A few questions:
1. So IIRC you would add Racket Mode using the new `:rolling-release` attribute. Going forward, if I push a new commit to the repo here on GitHub, it would automatically update on NonGNU ELPA, much like with MELPA?
Right.
2. On MELPA, the "version numbers" are timestamps. Out of curiosity, would it look like non NonGNU ELPA?
ELPA uses "inverted timestamps", ie. it appends the timestamp to the
current value of the version tag. Take for example org-mode:
https://elpa.gnu.org/devel/org.html. The version is:
org-9.6pre0.20221107.72305
This makes switching between development snapshots and actual releases
easier.
3. It look like a few packages currently use `:version-map` for what seems to be a rolling release, for example:
```elisp
("smartparens" :url "https://github.com/Fuco1/smartparens"
:ignored-files ("LICENSE" "dev" "doc" "images" "test")
;; See Fuco1/smartparens#1095
;;
;; Until a version tag is added, the commit of the latest tag is
;; used to mark the last stable release:
;; https://github.com/Fuco1/smartparens/releases/tag/1.11.0
:version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
```
No, this is used to pin a release for packages that don't have a version
tag. As I have mentioned above, the version tag is prepended to the
timestamp, so it is still necessary for the package to have a non-0
version (which won't mean much, and might as well consist of a single
number).
Out of curiosity, do you expect to change these to use `:rolling-release`, instead?
This has not been discussed. The main problem with these packages is
that they don't follow the packaging conventions that are elaborated in
(elisp) Simple Packages, requiring packages to have a proper version
tag. If the maintain requests the usage of a "rolling release" system,
we can grant that, but it is preferred to use the regular release
system.
Greg Hendershott ***@***.***> writes:
Two **tiny** questions/concerns:
1. The rules in README.org include:
> *** The package must follow the rules in
> https://www.gnu.org/prep/standards/, node References. This means it
> may not refer users to any nonfree software or nonfree
> documentation, except as stated there. Leading users to run a
> program, and suggesting they run it, or depending on it to be
> installed, are forms of referring users to it.
Although I'm not aware of doing this, currently, I also don't
worry about it. If some Emacs or Racket package seems relevant, then I
just point it out to people -- on the theory it's information: Each
person can decide if it is actually useful, and, usable (licensing),
for them.
In practice is that going to be OK, or, be a Huge Issue if something has e.g. MIT or no explicit license at all?
NonGNU ELPA does not insist on GPL code, as NonGNU ELPA packages are
explicitly not part of Emacs (as opposed to GNU ELPA). So MIT shouldn't
be a problem. No license is tricky, because that is -- legally speaking
-- non-free code that you are not allowed to modify, distribute, etc.
Is this something you anticipate?
2. The MELPA package definitions are in terms of files to include,
whereas the NonGNU ELPA ones seem to be in terms of files to
ignore. So e.g. once upon a time I added a new top-level `tests`
directory -- but didn't need to ask for the MELPA definition to be
updated. If I do that going forward, I'd need to contact you wrt
`:ignored-files`, correct?
You can also maintain these in your repository, by adding an .elpaignore
file that will list files to be excluded during packaging (in the
backend this makes use of GNU tar's "-X" flag).
(I'm not objecting, or asking you to change the definition model
just for me. Really I'm just double-checking what I might need to
remember to do differently.)
No problem, I'm glad to help!
All of this is documented in greater detail in the ELPA-Admin README:
https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README?h=elpa-admin.
|
No, I don't anticipate it. I was trying to say that I don't think about it, at all. If some package seems potentially useful, my inclination is to mention it -- and let each user do their own due diligence. The rule seems to say I should not even talk about the existence of non-free items (or whatever "refer" means here). Probably I am over-thinking this rule. If, someday, I list some "suggested package" that turns out to have a license defect, we can figure it out, then.
Oh, great. I had skimmed both README and README.org, but overlooked that. Thank you very much for your help explaining things. I think it all looks good now. What would be the next steps? Should I for example:
|
This for what issue #389 has evolved into. Note that, although we intend to be a "rolling release" package, some non-zero Version is still required, so add this back as Version "1". In the new .elpaignore, I'm not 100% confident about the glob complement pattern that intends to exclude all racket-mode.* files -- except do include racket-mode.texi.
|
I added a commit 22f45f6 with a first draft of updating |
|
Greg Hendershott ***@***.***> writes:
> NonGNU ELPA does not insist on GPL code, as NonGNU ELPA packages are
explicitly not part of Emacs (as opposed to GNU ELPA). So MIT shouldn't
be a problem. No license is tricky, because that is -- legally speaking
-- non-free code that you are not allowed to modify, distribute, etc.
Is this something you anticipate?
No, I don't anticipate it. I was trying to say that I don't think
about it, at all. If some package seems potentially useful, my
inclination is to mention it -- and let each user do their own due
diligence. The rule seems to say I should not even talk about the
existence of non-free items (or whatever "refer" means here).
Probably I am over-thinking this rule. If, someday, I list some
"suggested package" that turns out to have a license defect, we can
figure it out, then.
I would also expect that if any issue like this were to arise, they
could usually be resolved by a simple email exchange.
> You can also maintain these in your repository, by adding an .elpaignore
file that will list files to be excluded during packaging (in the
backend this makes use of GNU tar's "-X" flag).
Oh, great. I had skimmed both README and README.org, but overlooked that.
Yeah, they are a bit messy.
---
Thank you very much for your help explaining things. I think it all looks good now. What would be the next steps?
Should I for example:
- [ ] Add such an `.elpaignore`
Yes.
- [ ] Add back a `Version:` field to `racket-mode.el` (which I'd intentionally removed when I realized was really doing a rolling release)
Yes.
- [ ] Give you my attempt at the package definition for https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/elpa-packages
That is not necessary, I can take care of that.
|
|
Here is my current build log: I have also attached a tarball to this message so you can see how that looks like (I had to compress it because GitHub rejects plain .tar files?): racket-mode-1.0.20221107.124046.tar.gz Your .texi trick seems to have worked. |
Well, not quite. Experimenting with I was trying to be too clever, forcing it into an inclusion rule. I just changed that. Also I fixed some other things in As for those five image files: I'm not sure why it's referring to "(for HTML)" as opposed to the Info generation. I do generate HTML for the https://racket-mode.com web site. I'm not sure why your build script would attempt that by default? Are those warnings harmless in your opinion, or do we need to work on that? |
|
Greg Hendershott ***@***.***> writes:
> Your .texi trick seems to have worked.
Well, not quite. Experimenting with `tar -X .elpaignore` I noticed it let slip a couple files with 3-letter extensions, .org and .css.
I was trying to be too clever, forcing it into an inclusion rule. I just changed that.
Also I fixed some other things in `.elpaignore` (e.g. it was including
the whole `test` subdirectory), which I just force-pushed to that
topic branch in commit 7499927.
That seems to have worked.
Generally, do you force-push a lot? ELPA that prefers to fast-forward
the mirror if possible, so force-pushing can cause conflicts.
As for those five image files: I'm not sure why it's referring to
"(for HTML)" as opposed to the Info generation. I do generate HTML for
the https://racket-mode.com web site. I'm not sure why your build
script would attempt that by default? Are those warnings harmless in
your opinion, or do we need to work on that?
The documentation for every package is converted both to .texi and to
.html, one to be bundled with the package another to be distributed on
elpa.{non,}gnu.org (see https://elpa.nongnu.org/nongnu/doc/). My best
guess would be that that caused the message, but I would have to
investigate the issue some other time to be sure.
Either way, it is not a blocking issue.
|
Absolutely never to the main branch ( Sometimes I do force-push to a "topic" branch -- as in this case, the |
|
As for the doc warnings, thanks for confirming that. I think I've done all I need to, on my end? Of course please let me know if there's more that I should do, or anything I can do to help you. |
|
Greg Hendershott ***@***.***> writes:
> Generally, do you force-push a lot? ELPA that prefers to fast-forward
the mirror if possible, so force-pushing can cause conflicts.
Absolutely never to the main branch (`master`), to which ELPA would be pointed. In fact I have GitHub branches configured to guard against this.
Great!
Sometimes I do force-push to a "topic" branch -- as in this case, the
`nongnu-elpa` branch -- particularly if I know I'm going to squash
down to one commit before merging, anyway. And if the spirit is to fix
some typo or dumb mistake in the previous commit, and I don't think
anyone is really following along with the changes one by one. Sorry if
that caused any confusion, for you, here!
No worries, I just wanted to preempt any future issues.
Greg Hendershott ***@***.***> writes:
As for the doc warnings, thanks for confirming that.
I _think_ I've done all I need to, on my end? Of course please let me know if there's more that I should do, or anything I can do to help you.
It looks like it. I'll try and find the time to test the package this
week and report back if there are any issues or of the package was
released.
|
|
Oh, if you're pointing ELPA to the Even if there were problems or additional changes to make wrt to NonGNU ELPA, that should be N/A with respect to everything else (nothing else looks at |
Although not required, this is motivated by issue #389. A "README.org" will be automatically recognized without the package definition needing a :readme item. Furthermore, this is an Emacs package, we were already using org instead of markdown for some other files, and we may as well be consistent.
|
As a heads up, I just merged a commit changing a few So I think the definition would now be something like: ("racket-mode" :url "https://github.com/greghendershott/racket-mode"
:rolling-release t
:readme "README.org")or even (IIUC) simply: ("racket-mode" :url "https://github.com/greghendershott/racket-mode"
:rolling-release t) |
Don't merge this until it's actually available, and for example https://elpa.nongnu.org/nongnu/racket-mode.{html svg} exist. Related to #389.
|
A comment on the last commit:
NonGNU ELPA was added in Emacs 28.1. |
Don't merge this until it's actually available, and for example https://elpa.nongnu.org/nongnu/racket-mode.{html svg} exist. Related to #389.
Don't merge this until it's actually available, and for example https://elpa.nongnu.org/nongnu/racket-mode.html and .svg exist. Related to #389.
|
@phikal Not that it's necessarily urgent, but, do you know the next step(s) and timing for this appearing on NonGNU ELPA? Just wanted to make sure the ball isn't in my court. Also I will want to merge that docs update, not too long after it goes live there. |
|
Sorry for the delay, I was busy and now I am sick. Nevertheless, I've sat down and tested the package specification. It appears to work, so I have pushed it to nongnu.git and the package should appear soon enough. |
|
Oh, no. I hope you're feeling better, soon! Thank you again for the original issue submission, as well as following up over time, and especially for your help during this "home stretch". |
Thanks. One more thing I noticed is that the Author and Maintainer field have no Email address: https://github.com/greghendershott/racket-mode/blob/master/racket-mode.el#L7-8 Is this intentional or could you add an address to both? |
|
I see it appeared on https://elpa.nongnu.org/nongnu/racket-mode.html. 🎉 It's been intentional that I haven't supplied an email address. I don't want spam, and also, GitHub Issues is my only "inbox" to handle bug reports and feature requests in a public and transparent way. The docs explain and link to that. I had checked and saw the email is blank for some other NonGNU ELPA packages, so I figured it was acceptable. Although I'm open to discussing changing this, if it's really a big deal, it is probably (for me) really a whole discussion about how to manage issues (if not solely via GitHub), and so probably deserves its own new/fresh issue (here, ironically or not, for now). |
|
Greg Hendershott ***@***.***> writes:
I see it appeared on https://elpa.nongnu.org/nongnu/racket-mode.html. 🎉
It's been intentional that I haven't supplied an email address. I
don't want spam, and also, GitHub Issues is my only "inbox" to handle
bug reports and feature requests in a public and transparent way. The
docs explain and link to that.
I had checked and saw the email is blank for some other NonGNU ELPA packages, so I figured it was acceptable.
It is acceptable, in the sense that nothing will break, but if something
is broken, the ELPA maintainers (me included) would be more inclined to
send an email, than to open an issue on GitHub.
I have also been recently working on package.el, and have added a few
commands to contact package maintainers via Email. This relies on a
maintainer field in the package header with an email address. The
current configuration appears to indicate that there is a maintainer you
can contact, but the email address is invalid.
Although I'm open to discussing changing this, if it's really a big
deal, it is probably (for me) really a whole discussion about how to
manage issues (if not solely via GitHub), and so probably deserves
it's own new/fresh issue (here, ironically or not, for now).
To clarify your point, your main concerns are Spam and centrality of
development, right?
I could also ping Stefan Monnier ***@***.***) to see if he has anything to
add.
|
Yes. Sometimes on the Racket Discourse, Slack, IRC, or whatever, someone will mention an issue. Sometimes I will copy that into a newly created GitHub Issues item, here, and ask them to continue the conversation, here. It's not ideal, but it's rare. I'd rather not add an "official", email flavor of that flow. I do understand that GitHub is not ideal for everyone, on practical and/or philosophical grounds; that makes me feel bad. On the other hand, some of these issues or feature requests take a very long time for me to handle -- in some cases many days or weeks to fix or add something non-trivial for one person. I feel less bad thinking that, as part of the bargain, I ask for the workflow to be a certain way that's streamlined for me. |
Hi,
I'm a MELPA Stable user, which means that I can only install software from MELPA that has had a tag added to the repository to indicate a "stable" state. Sadly
racket-modedoesn't seem to have any published tags, so I wanted to ask if it a (somewhat?) stable point in history could be tagged?The text was updated successfully, but these errors were encountered: